Cream of the Crop 12/Cream of the Crop 12 (Part II)/Cream of the Crop 12 (Part II).iso/BBS/NEFD233.ZIP/NEF.INF

OS/2 Help File | 1996-03-13 | 137.2 KB | 5,497 lines

ΓòÉΓòÉΓòÉ 1. Readme First ΓòÉΓòÉΓòÉ


                        NEF Readme First


ΓòÉΓòÉΓòÉ 1.1. Files in the archive ΓòÉΓòÉΓòÉ


Files in the original archive:

File_Id.Diz    The standard archive description
Nef.Exe        The executable
Nef.Ico        An Icon for NEF
Nef.Inf        The Inf hypertextual Manual
Readme.1st     This file
Whatsnew.Txt   Changes and additions
Nef_Ful.Cfg    The full example configuration file
Nef_Pnt.Cfg    The minimal example cfg for points
Ticarea.Cfg    The example area configuration
Compress.Cfg   The example archiver-definition
Prefix.Nef     The example announcement prefix
Suffix.Nef     The example announcement suffix
NefHelp.Txt    The example Link Robot help file
Nef.Doc        The user's manual
License.Doc    The license for using this software
Register.Doc   Info on Registration
Register.For   The registration form
BmtMicro.For   The BMT Micro registration form
PsL.Crd        The PsL Credit Card registration form supplement

                           OS/2 Only

PmHatch.Exe    The PM hatch executable
PmHatch.Ico    An Icon to be associated to "Nef Send"

feature\
  Feature.Dll    An example Feature Dll
  Feature.C      Its source
  NeFeat.H       The necessary Include file


                            Dos Only

Dos4Gw.Exe     Dos Extender (major releases only)
               If you have a maintenance release of the program,
               the dos extender will not be included, to avoid
               unnecessary distribution costs.


Note: The Icons are kindly made available by Andrea Vavassori of
      2:331/219.

The Inf file (OS/2 manual) is provided with the DOS version too,
since there are INF viewers under Dos. For example, the very
nice viewer by Damir Ujcic: VIEW01.ZIP, available for F/R from
2:332/504@fidonet: it contains a text mode viewer in both OS/2
and Dos versions.


ΓòÉΓòÉΓòÉ 1.2. Whatsnew ΓòÉΓòÉΓòÉ

                            Whatsnew

If you are using an older version of the program, please read
WhatsNew.Txt before using this version.

DOS: If you do not have the DOS4GW.EXE dos extender, please
get the last major revision archive.


ΓòÉΓòÉΓòÉ 1.3. How to contact the author ΓòÉΓòÉΓòÉ


                    How to contact the author

If you have suggestions, bug reports, observations about the
docs, please feel free to contact me at the following
addresses:

Alberto Pasquale of 2:332/504@fidonet

[e-mail]

2:332/504@fidonet [phone] ISDNC V34+ VFC V32T H16
2:332/524@fidonet [phone] ISDNC V34  VFC V32T H16 FAX

Alberto Pasquale, Viale Verdi 106, 41100 Modena, Italy

IMPORTANT: if you call crash and require an answer, please state
whether you want it routed (might not be reliable) or ON HOLD
(in which case an answer should be available in 48h maximum,
apart from the holiday periods).


ΓòÉΓòÉΓòÉ 1.4. Support ECHO ΓòÉΓòÉΓòÉ


                         Support ECHO

I am originating an international support echo for all my
programs. If you are interested, please ask your echo feeder to
find a suitable link for the APWORKS area. In addition, I
regularly read the international OS2BBS echo.


ΓòÉΓòÉΓòÉ 1.5. TIC distribution ΓòÉΓòÉΓòÉ


                       TIC distribution

All my BBS related programs are distributed via a TIC file area.
If you want to join, please ask your file feeder to find a
suitable link for the APBBS (OS/2) and/or APBBSDOS (Dos) area.
Beta versions are distributed without restrictions in
APBBSBETA and APBBSDOSBETA respectively.


ΓòÉΓòÉΓòÉ 1.6. APWorks Programs and Support Areas ΓòÉΓòÉΓòÉ


                       Where to look for
               APWorks Programs and Support Areas


In North America the APWORKS support echo should be easily
available, since it is on the Zone 1 backbone.


The following systems carry the ApWorks echo and file areas:


                            Author's
APWORKS
    Alberto Pasquale, Modena, Italy
    [e-mail]
    2:332/504@fidonet [phone] ISDNC V34+ VFC V32T H16
    2:332/524@fidonet [phone] ISDNC V34  VFC V32T H16
    File requests could be declined between 23:00 and 06:00 GMT.
    Request APFILES for a (short) list of APWORKS files only.


                             Europe

ApWorks_Germany
    Roland Schiradin, Eltville, Germany
    [e-mail]
    2:2454/169@fidonet

Cyberia/2
    Harald Kamm, Bamberg, Germany
    2:2490/3045@fidonet

McBears Cave
    Jens Holm, Skanderborg, Denmark
    2:238/888@fidonet

The BackRoom/2 BBS
    Martin Davies, Cardiff, Wales, United Kingdom
    [e-mail]
    2:442/617@fidonet

Air Applewood
    Vince Coen, Roydon, Harlow, Essex, United Kingdom
    2:257/609@fidonet


                         North America

COMM Port OS/2
    Bob Juge, Sugar Land, TX, USA
    [e-mail]
    1:106/2000@fidonet

The CrossRoads
    Dave Reed, Puyallup, WA, USA
    [e-mail]
    1:138/135@fidonet

Eclectic Lab 1
    Mary-Anne Wise, New Westminster, BC, Canada
    1:153/831@fidonet


                           Australia

Tardis BBS
    Malcolm Miles, North Balwyn, VIC, Australia
    3:633/260@fidonet


ΓòÉΓòÉΓòÉ 1.6.1. File Areas on the Internet ΓòÉΓòÉΓòÉ


                   File Areas on the Internet

ftp.juge.com

ftp.wilmington.net/bmtmicro
    Only the final release versions (no betas) of programs that
    can be registered via Bmt Micro.

ftp.baynet.co.uk
    /pub/apworks/os2
    /pub/apworks/dos
    /pub/apworks/beta


ΓòÉΓòÉΓòÉ 1.7. Latest Versions ΓòÉΓòÉΓòÉ


                       How to Request the
               Latest Version of APWORKS Programs


The following magics are honoured by APWORKS and some of the
support sites:


Magic    Name         Description

FASTLST  FLST???.RAR  OS/2 The ultimate v7 Nodelist processor.
                           Fully automated processing and
                           maintenance, no need for clumsy batch
                           files. Can report to Squish or *.MSG
                           areas, multitasking friendly, many
                           options.

FASTLSTD FLSTD???.RAR DOS

FLSTBETA              OS/2 FastLst public Beta, if any.

FLSTDBET              DOS

NEF      NEF???.RAR   OS/2 TIC file distribution and
                           announcement for Binkley-style
                           outbound and *.MSG or Squish message
                           base, file-Areafix included with
                           FileBone support, full multitasking
                           aware (BSY, file sharing etc.),
                           exceptionally flexible Multi-Aka
                           support.

NEFD     NEFD???.RAR  DOS  32 bit only, w DOS4GW extender.

NEFBETA               OS/2 NEF public Beta, if any.

NEFDBETA              DOS  32 bit only, w DOS4GW extender.

FLM      FLM???.RAR   OS/2 File List Manager for Maximus,
                           very flexible way of compiling
                           many different lists at a time.
                           Internal file base support
                           (no need for FBP).

FLMD     FLMD???.RAR  DOS  32 bit only, w DOS4GW extender.

NMFW     NMFW???.RAR  OS/2 Multi-Robot: netmail forward to
                           Sysop's point, Maximus user and file
                           management via netmail messages,
                           areafix for squish, point routing to
                           their boss if no phone number for
                           them in the nodelist, etc.

NMFWD    NMFWD???.RAR DOS  32 bit only, w DOS4GW extender.

QFB      QFB???.RAR   OS/2 Substitute for FBP.EXE
                           Generates a separate file-request
                           index with no duplicates.

QFBD     QFBD???.RAR  DOS  32 bit only, w DOS4GW extender

SQPRV    SQPV???.RAR  OS/2 Local area (private/public) forward
                           to points for Squish. The (Co)SysOp
                           points can receive the whole area.

SQPRVD   SQPVD???.RAR DOS

-----    SQFM100.RAR  OS/2 Allows to change the "from address"
                           of PKTs before they are compressed.
                           To be used with Squish.
                           For example, it is useful to Hub
                           coordinators who want to continue
                           processing mail with their primary
                           address for current links while
                           processing with the administrative
                           address for their uplink BackBone.
                           FreeWare.

-----    SqSetAll.Rar OS/2 Sets renum limits in all Squish Areas
                           taking the parameters from
                           Squish.Cfg.

-----    SqSetDos.Rar DOS  Dos version.

-----    AdjFDate.Rar OS/2 Changes by +-N days the File Date.
                           Can choose between Creation and
                           Modification dates on HPFS.
                           Show and Touch options.

-----    AdjF_Dos.Rar DOS  Changes by +-N days the File Date.

-----    UR2_100B.EXE OS/2 UnRar decompressing program,
                           freeware.


Current versions (March 13th 1996): NEF 2.33, FastLst 1.31,
FLM 1.34, NMFWD 2.01, QFB 1.07, SQPrv 1.04.


ΓòÉΓòÉΓòÉ 1.8. Bug Reports ΓòÉΓòÉΓòÉ


                         Bug Reports

If you find out a real bug, I will do my best to fix it and make
the new version available in a few days. To do that, I need your
cooperation: when you find a strange behaviour, double check
your configuration and the manual to be really sure it's not
your fault, then study the conditions in which the bug appears
and, in the end, send me your detailed report about the bug
together with your config file and all the stuff necessary to
replicate the problem. I can fix a bug only if I am enabled to
reproduce it !


ΓòÉΓòÉΓòÉ 1.9. Wish List ΓòÉΓòÉΓòÉ

                        Wish List


To help me provide a better and better program, please let
me know your problems and your wishes about future versions.

Please let me know your opinion:

Alberto Pasquale 2:332/504@fidonet
[e-mail]

BBS:     [phone] ISDNC V34+ VFC V32T H16
BBS/FAX: [phone] ISDNC V34  VFC V32T H16 FAX

Viale Verdi 106
41100 Modena
Italy


ΓòÉΓòÉΓòÉ 2. Whatsnew ΓòÉΓòÉΓòÉ


                              NEF

                     Changes and Additions


ΓòÉΓòÉΓòÉ 2.1. 2.33 ΓòÉΓòÉΓòÉ


2.33   Public Release, Mar 13 1996

     - A bug in the squish.cfg parsing routines has been found:
       if an area is defined with NOTHING after the path, this
       area cannot be opened. The problem usually happens when
       AreaTag specifies a *.MSG netmail with NO flags in
       Squish.Cfg.


ΓòÉΓòÉΓòÉ 2.2. 2.32 ΓòÉΓòÉΓòÉ


2.32   Public Release, Mar 13 1996

     - New registration options: BMT Micro, NC, USA and Vince
       Coen, UK.

     - If the file description contains high ascii codes
       (>127), the announcements will now contain remapped
       plain-ASCII characters.

     - You can allow High Ascii characters in some (or even
       all) areas by the use of the "HighAsciiOk" statement in
       the global or local-override announcement sections.

     - New (global) statement: UniqueDmpLine.
       Makes NEF generate FILES.DMP filebase files with
       descriptions on one line only (multiple lines are
       concatenated).

       By default, NEF outputs multi-line descriptions without
       changes to FILES.DMP: when using L)ocate and N)ewfiles
       commands, Maximus will respect the original formatting,
       but the continuation lines will be aligned to the left.

       When this statement is used, the original formatting of
       descriptions is lost (in the filebase) but Maximus will
       be able to word-wrap and align when executing L)ocate or
       N)ewfiles commands.

     - Added check to prevent misconfiguration of the "AreaTag"
       statement: it's ILLEGAL to use "AreaTag MyTag -$".
       You must either use "AreaTag MyTag" (if SquishCfg is
       used) or "AreaTag MyTag c:\bbs\mail\mytag -$".
       In other words: when you let NEF lookup the TAG in
       Squish.cfg, it is smart enough to find out the area type
       on its own !

     - When hatching from command line, it is now legal to specify
       @diz without specifying a short description: it will be
       considered empty. I still strongly recommend to always
       specify a "short" description besides the optional "long"
       one.

       Example

       Nef Hatch c:\file\filename.ext TAG @diz

       is now equivalent to:

       Nef Hatch c:\file\filename.ext TAG "" @diz

     - Changed a typedef in NEFEAT.H, so that it does not
       create problems with IBM compilers (thanks to Michael
       Hohner).

     - OS/2: New mnemonic characters for PmHatch PushButtons.


ΓòÉΓòÉΓòÉ 2.3. 2.31 ΓòÉΓòÉΓòÉ


2.31   Private Beta, Mar 3 1996

     - Fixed problem with UNC filenames that start with a double
       backslash (on LANs).


ΓòÉΓòÉΓòÉ 2.4. 2.30 ΓòÉΓòÉΓòÉ


2.30   Public Release, Feb 19 1996

     - Check added to prevent NEF from issuing a forward request
       to multiple uplinks for the same area, when a TAG is
       contained in more than one Filebone file.

     - New cfg statement: "ForwardWildReq".
       Starting with ver 2.30, by default, TicFix requests with
       wildcards are NOT forwarded to the filebones; this verb
       enables even this type of request forward.

     - Additional check in PmHatch: if no "short" description is
       specified, the user is prompted about whether he really
       means to hatch with no (short) description.

     - Updated Docs.


ΓòÉΓòÉΓòÉ 2.5. 2.26 ΓòÉΓòÉΓòÉ


2.26   Public Beta, Jan 22 1996


     - COMPATIBILITY WARNING:

       New override priority sequence for "from AKA".

       The highest priority is that of the "Area AKA": if you
       have defined an area aka (#<address> in FileArea
       definition), it will always be the "from address" for
       TICs from this area.

       Then there is the aka override of "FileLink" definitions.
       If a node has a "from aka" specified in it's FileLink
       definition, it will be used for all TICs addressed to
       this node, unless there is an overriding "Area AKA".

       If no override is applicable from FileArea and FileLink
       definitions, then an aka match is attempted: if the
       "to-address" has a zone that matches an address defined
       in NEF.CFG, then the first match is used.

       If none of the previous cases applies, the primary
       address is used (the first address defined in nef.cfg).


     - New command line options for hatch commands.

       "@bbs" can be used in the place of the normal
       description: NEF will take (if existent) from the
       files.bbs.

       "@diz" can be used as a further optional parameter (after
       the "short" description) to make NEF take the "long"
       description from the file_id.diz contained in the
       archive.

       Examples:

       nef hatch d:\apbbs\nef999.rar APBBS "Nef 9.99"
       nef hatch d:\apbbs\nef999.rar APBBS @bbs
       nef hatch d:\apbbs\nef999.rar APBBS "Nef 9.99" @diz
       nef hatch d:\apbbs\nef999.rar APBBS @bbs @diz


     - New "Single Hatch" option.
       If you Hatch/Catch/Match/Send a file with the -d<adr>
       command line switch, it is sent to <adr> only.

       <adr> can be any 4D address: in the case it is defined as
       a link in the matching "FileArea" or even only as a
       "FileLink", the specified akas, password and switches are
       applied.

       If, on the contrary, <adr> is a unknown address,
       the Hold flavour is used, no password is put in
       the TIC and the "from" aka is derived from an aka-match
       on the zone.

       Example: Nef -d2:332/504.2 hatch


     - Now NEF is able to add new (created) areas to the Maximus
       filearea.ctl or equivalent.
       There are two new configuration statements:

       MaxAreaAdd <fileareactl> <lev[/keys]> <acs> [<division>]
       MaxAreaCompile <command>

       <fileareactl> is the fully qualified name of the Maximus
       file-area definition file.

       <lev[/keys]> protects areas of higher privilege from
       being automatically added to the Maximus configuration.
       The level and keys are to be compared to those of
       ProtArea statements and FileBone files.

       <acs> is the Maximus access string to be used in
       <fileareactl> for the new area.

       <division> is the optional specification of a division
       where you want to put new areas. If not specified or not
       found, the new areas will be appended at the end of
       <fileareactl>.

       <command> is an external command to be executed before
       NEF ends, from the Maximus system directory.
       It should be used to compile the new Maximus
       configuration via SILT/SILTP.

       The area name is taken equal to the area TAG, with dots
       changed to underscores.

       The area description is taken from the FileBone files if
       available, otherwise it is taken equal to the area TAG.

       Example:

       MaxAreaAdd d:\max\filearea.ctl 0 Transient Tic.New
       MaxAreaCompile siltp max -a -2a

       The new areas, will be inserted at the end of division
       "Tic.New" in the file "d:\max\filearea.ctl", with an
       access string of "Transient". Areas with protection level
       above 0 or any protection key will NOT be added to
       maximus configuration.

       Before terminating, NEF will invoke the SILTP compiler to
       update the area configuration. The command will be
       executed after changing the current directory to the
       Maximus system one (probably d:\max\).


     - The filebone-style files now accept the specification of
       keys after level.

       Example:

       Area NODEDIFF 0/f ! FidoNet: Weekly NodeList Updates


     - The default message size is of 12KB.
       The new cfg statement "MsgSize <bytes>" allows to specify
       a different size (minimum 8KB).

       Usually a larger message size is useful to avoid too many
       messages in reports of filebone availability. Anyway,
       please be careful not to use a size larger than your
       downlinks can handle.

       Example:

       MsgSize 90000


     - Fast Netmail Scan in Squish area.
       The pointer to the last scanned message is stored
       in <netarea>.NEF.


     - New cfg statement "NoRaidBeforeHatch" to avoid the
       scanning of netmail before the execution of hatch
       commands. This could be useful to avoid delays with huge
       *.MSG netmail areas.


     - The tear line now reports the OS version (OS/2 or DOS)
       and a '+' after the version number in the case of a
       registered copy ("Evaluation" for unregistered copies, as
       before).


     - Errorlevels for Lock and Close error on message areas
       have been dropped: if a Lock error happens, NEF will exit
       with the Open area errorlevel; in the case of a Close
       error, NEF will continue after issuing an error message.


     - TICs received with no password in "NoSecure" mode are
       accepted anyway.


     - Area aka overrides are reported by the nef filefix robot
       when answering to query type commands.


  OS/2 Only:

     - Added support for Feature DLLs:

       Two new configuration statements are supported:

       FeatureLoad <DllName>
       Feature <cfgline>

       "FeatureLoad" allows to load a "Feature" DLL.
       <DllName> can be a simple filename without extension
       (".DLL" implied) if the DLL is in the LibPath, otherwise
       a fully qualified filename can be specified.

       "Feature" allows to specify configuration statements that
       are to be parsed by the DLL.

       Multiple FeatureLoad statements are allowed, in which
       case the Feature statements refer to the last loaded DLL.

       An Example DLL, named "Feature.Dll" is provided, with
       source.

       Example (works with the example DLL):

       FeatureLoad Feature
       Feature OutPrefix "New File Received: "


ΓòÉΓòÉΓòÉ 2.6. 2.21 ΓòÉΓòÉΓòÉ


2.21   Public Beta, Jan 1 1996

     - This should be the last beta before a new "final" release.

     - COMPATIBILITY WARNING:

       The old "AreaList" configuration statement has been dropped.
       In some cases you could use the new "HelpFile" statement
       to point to the file you used with "AreaList".

     - New "HelpFile <file>" configuration statement.
       The specified <file> will be sent (via netmail) by the
       FileFix robot when help is requested.

     - New switches can be used on the subject of messages
       addressed to the FileFix robot:

       -h  to ask for help.
       -q  remains "query": list of all areas.
       -l  now means "linked": list of linked areas only.
       -u  to get a list of unlinked areas only.

       Only the first letter is checked, so you could use
       "-query" instead of the simple abbreviation "-q".

     - New commands are now available in the body of the
       messages addressed to the FileFix robot.
       Besides add/delete commands for areas, you can use:

       %Help        same as -h
       %Query       same as -q
       %List        same as -q
       %Linked      same as -l
       %Unlinked    same as -u

     - New "FileBone" support.

       NEF is now able to use information distributed via the
       FileBone.Na and FileBone.No files.

       Many useful functions are allowed by the use of these
       files, so, even if you do not receive them from your
       uplink, you could evaluate the possibility of creating
       "filebone" style files on your own, just to store some
       information that can be retrieved by NEF.


     - The format for the filebone style is:

       Area <Tag> <lev> <flags> <desc>

       <Tag> is the TIC area Tag. The original filebone format
             allows 8 character maximum but NEF is not that
             limited.

       <lev> is the protection level of the area, for "filefix"
             (raid) functions.
             The original format allows the range 0-4095 while
             NEF allows 0-65535.

       <flags> is a combinaton of !.*& and possibly other
               characters.

             ! : Can be found at any Filebone Hub.
             . : Only on some Filebone Hubs.
             * : Any node can hatch into.
             & : Do not send to downlinks.

        Others : Private distribution.

        Examples:

             ! : normal area from the uplink to its downlinks,
                 available on all Filebone Hubs.

           !*& : return channel from the downlinks to their
                 uplink, available on all Filebone Hubs.

            .* : bidirectional area (any node can hatch into),
                 available on some Filebone hubs only.


       <desc> is the description for the area.


       Example:

       Area APBBS    0 P ApWorks OS/2 BBS programs
       Area NODEDIFF 0 ! FidoNet: Weekly NodeList Updates

     - New configuration verb:

       FileBone <file> [<fm> <to> <toadr> <acc> [<pre>]]

       Multiple FileBone statements are possible.

       <file> is the filename of the filebone-style file.

       If you want to enable the forward of requests for new
       areas from your downlinks to your uplink(s), you must
       specify the following fields (to be enclosed between
       quotes when containing space) so that they can be used to
       write netmail messages to your uplink's Raid:

       <fm> is the "from" name.

       <to> is the "to" name.

       <toadr> is the "to" 4D address.

       <acc> is a <level>[/keys] specification, to limit the
             access of downlinks to request forwards addressed
             to <toadr> for the areas described in <file>.

       <pre> is an optional string to be prefixed to the area
             Tags that are being requested.

       Examples:

       FileBone \bbs\FileBone.Na "Alberto Pasquale" SysOp 2:332/1 0

       The "\bbs\FileBone.Na" file is used by NEF, also for
       request forwards.

       When a downlink requests an area that is not currently
       defined in the NEF configuration (usually TicArea.Cfg)
       but is described in FileBone.Na, a netmail message is
       written by NEF from "Alberto Pasquale" to "SysOp" of
       2:332/1 using the appropriate "from address" aka and
       "subject" (password) as per the "FileLink" definition of
       2:332/1. The body contains a list of the requested area
       Tags, one per line.

       No (<acc> = "0") protection is specified (any downlink
       has access to request forwards).


       FileBone \bbs\FB.SP "Alberto Pasquale" SysOp 2:332/1 30/a +

       Only downlinks with level equal or above 30 and with the
       'A' key have access to request forwards. The requested
       tags will be preceded by "+".

       If you need a space between the '+' and the tag, then you
       must specify a <pre> that contains a space, so you have
       to enclose it in quotes:

       FileBone \bbs\FB.SP "Alberto Pasquale" SysOp 2:332/1 0 "+ "

     - The forwarded requests are stored in a file named after
       the configuration one, changing the extension to ".Fwd".
       Usually the configuration file is "Nef.Cfg", so the
       forwarded requests will be stored in "Nef.Fwd".

       The format is: <Tag> <Addr>, i.e. every line contains a
       Tag followed by the 4D Address of the downlink that made
       the request.

       When a new area is created, NEF looks into this file in
       order to find nodes to be added to the new "FileArea"
       definition.

     - A node is entitled to add an area only if it has level
       and keys that match the requirements from BOTH the
       "ProtArea" statements in Nef.Cfg and the <lev>
       specification in a FileBone file (if available).

     - The various area-listing commands will list the
       descriptions contained in the FileBone files.

     - When the FileFix robot is requested a list of areas that
       are not linked, it will list also those available to the
       requesting node from the filebone.

     - New cfg statement:

       AreaDescWrap <indent> <right>

       suggested:

       AreaDescWrap 25 79

       The descriptions returned by the filefix functions will
       be word-wrapped so that continuation lines start with
       <indent> spaces and do not exceed column <right>.

     - New extended syntax for the Netmail statement:

       NetMail <path> [-$] [-p<adr>]

       The new -p<adr> switch allows to specify a primary
       address for the netmail area. NEF will use this address
       to write the messages to the FileBone's FileFix to the
       correct netmail area.

       If you have multiple netmails, please add the primary
       address specification in all but the "default" netmail
       areas.

     - New command line command:

       NEF NOTIFY [ALL | <adr> ...]

       The Notify command sends a list of linked areas to the
       specified links.

       Examples:

       NEF Notify
       NEF Notify All

       Sends notification to all links.

       NEF Notify 2:332/504 81:449/9108

       Sends notifications to the 2 specified addresses.


ΓòÉΓòÉΓòÉ 2.7. 2.20 ΓòÉΓòÉΓòÉ


2.20   Public Beta, Dec 03 1995

     - New type of hatch with copy:

       If you use "NEF CATCH", the specified file is copied to
       the destination area and hatched.

     - Multi-Line files.bbs descriptions are now supported.
       To enable this feature the way you like, please use the
       "MultiLineDesc <nnn> [<c>]" statement, specifying the
       continuation column and character.

       For example, to have the 2nd and following description
       lines in files.bbs start at column 31, use:

       MultiLineDesc 31

       To have the continuation lines preceded by a '|'
       character, use:

       MultiLineDesc 29 |

     - Modified routines for PassThru clean-up.

       Previously passthru areas HAD to be defined using a
       separate path for each area. Now NEF works correctly even
       if you define many areas with the same path.

       Anyway this is not a recommended practice, since slightly
       different files with the same name could arrive from
       different areas causing a CRC mismatch.

   OS/2 Only:

     - New Pm Hatch.
       To invoke the PM hatch program you must type "NEF send".
       The PmHatch program is very simple and intuitive to use:
       see the following description.

       You can select the destination Area Tag via a drop-down
       list: just click with the mouse on the button at the
       right of the entry field.

       You have three radio buttons to select the "type" of
       hatch (normal, with Copy, with Move), just as you use
       Hatch/Catch/Match from the command line.

       You can choose the file to be hatched via a file dialog
       box: just click on the "Browse" push button on the right
       of the field.

       You can also specify a "Replace" file via a file-dialog
       by clicking on the "Browse" push-button on the right of
       the "Repl" field.

       When doing Copy or Move, the files.bbs of the destination
       area is updated and the "replace" file (if specified) is
       deleted, just as if the file were tossed from the
       inbound.

       You can mark the "No Local Kill" checkbox to prevent NEF
       from deleting the "replace" file in the local area.

       You can load a "short description" (Desc) from the
       files.bbs, by clicking on the "FilesBbs" push-button.

       You can load a multi-line "long description" (Long Desc)
       from the File_Id.Diz inside the archive, from the
       Files.Bbs or from a specified file (Arc Diz, FilesBbs,
       File push-buttons respectively).

       If you do not have the "CompressCfg <filename>" statement
       in Nef.Cfg, the "Arc Diz" push-button will be disabled.

       Of course you can always fill-in or modify any field
       manually.

       Now look at the five push-buttons at the bottom of the
       hatch dialog:

       <OK>: to exit the dialog and hatch all the entered files.

       <Prev>: to visualize the previous hatch entry.

       <Next>: to create a new (empty) entry in order to hatch
               another file.

       <Copy>: to copy the visualized entry to the first free
               position, in order to hatch another file by
               modifying the current entry.

       <Cancel> or ESC: to cancel the current entry.

       ALT-F4 or "Close", to abort (cancell all the hatch
              entries).

     - Please note that the PmHatch.Exe file must be in the path
       when you invoke "Nef Send". In the case the PmHatch
       program terminates abnormally, the NEF program will
       wait for it indefinitely: you can stop it using CTRL-C or
       CTRL-Break.

     - To allow the extraction of File_Id.Diz while using the Pm
       Hatch, use the "CompressCfg <filename>" statement to
       specify the location and name of a "Squish style"
       compress.cfg:

       CompressCfg c:\squish\compress.cfg


ΓòÉΓòÉΓòÉ 2.8. 2.19 ΓòÉΓòÉΓòÉ


2.19   Public Beta, Oct 04 1995

     - Please note:

       APWORKS has changed phone number:

       2:332/504@fidonet [phone] ISDNC/V34/VFC/V32T/H16
       2:332/524@fidonet [phone] ISDNC/V34/VFC/V32T/H16/FAX

       A new registration site is available:

       Jens Holm of 2:238/888@fidonet
       Skanderupgade 9, D2
       8660 Skanderborg
       Denmark

       Price: 125.- DKR.

       Can be paid cash, check or postal order.

     - ATTENTION: this version is for use with Maximus 3.00;
       support for Maximus 2.0x has been dropped. If you still
       use Max 2.0x you have to disable filebase support or
       continue using version 2.18.
       If you do not use Maximus, you can obviously use whatever
       version of NEF you like.

     - New mutual exclusive semaphore flag "FileBase.Bsy" used
       to avoid concurrent access and modification of the
       filebase by other ApWorks programs.
       There is no need to delete this flag if it is not deleted
       after a power failure or abnormal termination (ApWorks
       programs are smart enough to realize whether the flag is
       really in use or not).

     - New errorlevel 17 for FileBase Busy Timeout.

     - Support for the "MAXIMUS" environment variable: the
       "MaxPrm" cfg statement is now only an override.
       Please note that if the "MAXIMUS" variable is not
       defined, you must use the "MaxPrm" statement BEFORE
       "FileBaseUpdate".

     - When the files are touched in HPFS, the creation date is
       modified, not the modification one, in order to make the
       files recognized as new by Maximus and FLM without
       changing the date that is normally shown and transferred:
       you "see" and transfer to your downlinks the original
       date of the file while Maximus and FLM are able to
       realize that the file is new.

     - WildTags are now interpreted following the "OS/2 style"
       for file wildcards: "*LOC*" specifies all tags that
       contain "LOC"; "FW???" specifies all tags that have up
       to three characters after "FW", etc.


ΓòÉΓòÉΓòÉ 2.9. 2.18 ΓòÉΓòÉΓòÉ


2.18   Public Beta, Aug 28 1995

     - KeepSeenBy statement dropped: SeenBys are now already
       kept.

     - SeenBys are now always fully processed as they should.

     - Points are not included in the SeenBys of TICs addressed
       to other links, to avoid unnecessarily huge lists of
       SeenBys.

     - Fixed bug of Dos 2.17 version that prevented NEF from
       moving files between different logical drives.

     - Description is now formatted between columns 4 and 79, to
       make descriptions with empty lines look better.

     - The outbound functions (Out, OutView, Clean) can now
       handle 2000 files instead of 1000 (?UT, ?LO).

     - PassThru areas implemented: new "-0" option in "FileArea"
       statement.

       FileArea <TAG> <path> I|O|* [#<adr>] [-0] [[<flags>[link]...]

       When the "-0" is specified, the area is "PassThru", that
       is its files will be deleted when already sent to all the
       downlinks.

       Please note that ANY file (apart from FILES.*) present in
       <path> and not attached to any system will be deleted.

     - Since it might be not efficient to always scan the entire
       outbound to check for passthru files to be deleted, NEF
       must be instructed to do so.
       There are two ways to make NEF delete old passthru files:
       - Use -p command line switch.
       - Use CLEAN command line command.

       Examples:


       NEF -p

         Makes NEF operate as usual, but it will clean the
         PassThru areas before terminating.


       NEF -p OUT

        Makes NEF clean the PassThru areas and report the status
        of Outbound. This is the most efficient use, since NEF
        must scan the outbound once to make two different things
        ("clean passthru" and "outbound report").


       NEF CLEAN

        Makes NEF clean the PassThru.


     - The OUT and OUTVIEW commands are now equivalent for
       message output. When using file output ("NEF OUT Out.Txt"
       or "NEF OUTVIEW Out.Txt") OUT generates a concise
       Outbound analysis (no specification of each and every
       attached file), while OUTVIEW generates a full report.

     - The <OUT> special tag in "Announce" statements now makes
       NEF write a concise outbound report.

     - The new <OUTVIEW> special tag provides for a detailed
       outbound analysis.

     - New special tag <THRU> represents all passthru areas.
       If you want to keep NEF from announcing files received
       in PassThru areas, just use "NoAnnounce <THRU>".

     - New extensions in "NewAreasFrom" statement:

       NewAreasFrom <adr> [#<aka>] [-0] [<path>]

       The "-0" switch allows to create PassThru areas when a
       unknown TAG is encountered.

       The <path> is an override for the global "NewAreasPath"
       statement.


ΓòÉΓòÉΓòÉ 2.10. 2.17 ΓòÉΓòÉΓòÉ


2.17   Public Beta, Aug 10 1995

     - 16 bit versions dropped.

     - (OS/2) EAs are now copied together with the file, when it
       must be moved from inbound to the destination area.

     - Fixed bug that caused newly created areas to be added
       multiple times to ticarea.cfg if 2 or more areas were
       created at the same time.

     - When "MATCHing" a file that is already in its destination
       directory, it was deleted. Fixed.

     - Multiple "Desc" keywords in the inbound TICs are now
       recognized properly. Previously only multiple "LDesc"
       keywords were allowed; "Desc" had to be unique.

     - The description for FILES.BBS is now always taken from
       the "Desc" keyword(s) in the inbound TICs. Previously the
       "LDesc" description was used if longer. Reason: many
       "LDesc" descriptions contain boxes and look ugly when
       reformatted. The Files.BBS description does not allow to
       keep formatting (must be on a single line, the BBS
       program will reformat according to its configuration).

     - The description for announcement messages is the longest
       one between "Desc" and "LDesc". Its formatting is now
       preserved.

     - Now the '*' wildcard used alone does not include special
       tags (beginning by '<'). People using "Announce *" will
       not be disappointed any further by the announcing of
       <BAD> in the same area.

     - The Path statement in outgoing TICs contained the ASCII
       local (instead of GMT) time specification followed by
       "GMT". Now this has been fixed and the "GMT" changed to
       "UTC". Please note that you must have the environment
       variable "TZ" correctly set in config.sys (OS/2) or
       autoexec.bat (DOS) to have a correct specification of
       UTC.

       E.g. for Central European Time (CET)
       SET TZ=CET-01  (winter, normal time)
       SET TZ=CET-02  (summer, daylight saving time)

       E.g. for USA East Coast:
       SET TZ=EST5EDT
       Eastern time is 5h less than UTC and Daylight saving
       applies with the "standard rule" from the first sunday of
       April to the last sunday of October.

       More complicate expressions could be used to specify
       automatic change to and back from daylight saving, if a
       fix rule is available.

       E.g. for Italy: daylight is 1h ahead from last sunday of
       March to last sunday of September.

       SET TZ=CET-01CDT,M3.5.0,M9.5.0

       (See a C manual for more details).


     - New "NoSecure" (global) cfg statement to disable the
       Secure mode. When "NoSecure" is used, NEF will toss
       incoming files ignoring errors due to password mismatch
       and missing from-authorization (sender not linked, sender
       receive only). Anyway the error will be noted in the logs
       and <BAD> message report.

     - New "-t" command line switch to toggle "Secure" mode.

     - New (global) cfg statement "SquishCfg <filename>". It is
       used to find the path of a message area from its TAG.
       Required to use the new "AreaTag" statement in "short"
       form.

     - New "AreaTag <Tag> [<path> [-$]]" statement, to be used
       in the place of "AreaPath <path> [-$]". You can now
       specify an announcement area by using its TAG, as
       specified in Squish.Cfg.

       e.g.
       AreaTag LOCAL_ANNOUNCES

       The "long form", with both <Tag> and <path>
       specifications is useful in the case you do not use
       Squish and still want to tell NEF the TAG for an echo
       area, so that it can log it to EchoTossLog.

     - New "EchoTossLog <filename>" (global) cfg statement. NEF
       will log to the specified file the tags of the echoareas
       where it has written announcements. If you use the
       "MaxPrm" statement, you can omit "EchoTossLog", since NEF
       will take the default from the MaxPrm.

     - New "MaxPrm <filename>" (global) cfg statement. It is
       used to take the default for EchoTossLog and to get the
       name and location of the files necessary for filebase
       updating. This is required when using "FileBaseUpdate".

     - New "FileBaseUpdate" (global) cfg statement.
       Requires "MaxPrm".
       NEF will automatically update the filebase for all the
       areas changed when tossing/hatching new files. No more
       need for external FB.

     - New "NoReplace <WTAG> ..." (global) cfg statement.
       Multiple statements can be used. The specified <WTAG>s
       indicate in which areas you do not want NEF to delete
       files specified by the "Replaces" keyword in inbound
       TICs.

       E.g.: to avoid Replace in all areas:

       NoReplace *


ΓòÉΓòÉΓòÉ 2.11. 2.16 ΓòÉΓòÉΓòÉ


2.16   Restricted Beta

     - The special tags (e.g. <BAD>, <DEF>) can now be
       excluded from announcement via the "NoAnnounce"
       statement, just like all the normal tags.
       This is useful for people who like announcing all
       the areas together ("Announce *") and that were
       annoyed by the inclusion of the special tags
       also.


ΓòÉΓòÉΓòÉ 2.12. 2.15 ΓòÉΓòÉΓòÉ


2.15   Public Beta, Nov 11 1994

     - Be aware that all DOCS refer to version 2.00:
       updated documentation will be included in next
       version. For now, please read this file to know
       new features and changes.

     - The former support BBS (Videl, 2:332/504 511 524)
       will close in a few days. A new support BBS
       (ApWorks) is available with the same old address
       2:332/504; V34/VFC [phone].
       New Magics available for NEF beta: NEFBETA (OS/2)
       and NEFDBETA (Dos).

     - OS/2 versions are now compressed with InfoZip.

     - Fixed a problem that occurred when "short
       descriptions" (in "Desc" lines) were longer than
       255 characters. Nef considered the remaining of
       the description as an "unknown" line and put it
       in the outbound TICs. Now the remainder of a too
       long inbound-TIC line is discarded.

     - The "short description" limit has been raised to
       2KB (the same as for the "long description").

     - When both the "short" (Desc) and "long" (LDESC)
       descriptions are available, NEF uses the longer
       one for announcements and FILES.BBS. Up to
       v.2.14, NEF always used the "long" description
       if available.


ΓòÉΓòÉΓòÉ 2.13. 2.14 ΓòÉΓòÉΓòÉ


2.14   Public Beta

     - Support for Long Tags
       Now the area TAGs are not limited to 8 chars and
       can contain any character.
       Anyway you should be careful because other
       TIC processing programs could not be capable of
       handling such long tags.
       For sake of completeness, they can even contain
       blank spaces: where they could be misinterpreted
       as field separating characters, you must include
       the whole Tag in quotes: "Long Tag".
       See the DOC for more details.

     - Hatch/Match (batch mode):
       the character for separating the name and the
       replace fields has been changed from ',' to '/'.

     - The "BefDesc" statement has been substituted by
       the "DescStart" one.
       Here is a comparison of old and new syntax:
       BefDesc <WTAG> [<WTAG> ...] "<string>"
       DescStart "<string>" <WTAG> [<WTAG> ...]

     - Now there are 4 different EXEs.
       NEF.EXE:    32 bit OS/2
       NEF16.EXE:  16 bit OS/2
       NEFD.EXE:   32 bit DOS, requires DOS4GW.EXE
       NEFD16.EXE: 16 bit DOS

     - The "areafix" robot ignored messages marked as
       sent. Now they are processed, to avoid problems
       with netmail packers that mark all messages as
       sent, even if they are sent nowhere, being
       already arrived at destination.

     - New command line switch to override the
       "StatusLog" filename: "-l<logname>".

     - The maximum length of messages created by robots
       before splitting has been elevated to 12KB.


ΓòÉΓòÉΓòÉ 2.14. 2.12 ΓòÉΓòÉΓòÉ


2.12   Beta

     - Fixed bug that caused access violations when
       doing "NEF Out".


ΓòÉΓòÉΓòÉ 2.15. 2.11 ΓòÉΓòÉΓòÉ


2.11   Beta

     - Messages generated by NEF in multiple parts now
       have a time stamp that increases one second for
       each message part, thus avoiding false duplicate
       detection by the buggy dupe check of Squish 1.10.


ΓòÉΓòÉΓòÉ 2.16. 2.10 ΓòÉΓòÉΓòÉ


2.10   Beta

     - New function: "Outbound Analysis".
       Syntax: NEF OutView [<file>]    (verbose)
               NEF Out [<file>] (tiny)

       If <file> is not specified, the report goes to
       message areas. To define a message area for
       report, use the "<OUT>" keyword as a TAG. In this
       case, the Subj, Prefix and Suffix will be
       ignored.


ΓòÉΓòÉΓòÉ 2.17. 2.00 ΓòÉΓòÉΓòÉ


2.00 - First public release for the completely new NEF (OS/2 and
       DOS).

     - Added the <DEF> and <BAD> special tags for
       announcements.

     - Documented the NoAnnounce statement (already present in
       NEF v1.00).

     - Added the Tic processing and Link Robot sections.


ΓòÉΓòÉΓòÉ 2.18. 1.00 ΓòÉΓòÉΓòÉ


1.00 - First public release (DOS only).


ΓòÉΓòÉΓòÉ 3. Copyright ΓòÉΓòÉΓòÉ

**************************************************************
*                                                            *
*                                                            *
*                   **   ** ******* *******                  *
*                   ***  **  **   *  **   *                  *
*                   **** **  ** *    ** *                    *
*                   ** ****  ****    ****                    *
*                   **  ***  ** *    ** *                    *
*                   **   **  **   *  **                      *
*                   **   ** ******* ****                     *
*                                                            *
*                                                            *
*                        Version 2.33                        *
*                                                            *
*      File Distribution for "BinkleyTerm Style" Systems     *
*                                                            *
*                                                            *
**************************************************************
*                                                            *
*       (C) Copyright 1991-1996  by  Alberto Pasquale        *
*                                                            *
*           A L L   R I G H T S   R E S E R V E D            *
*                                                            *
**************************************************************


    "BinkleyTerm" is trademark of Bit Bucket Software, Co.



        NEF 2.33 User's Manual, by Alberto Pasquale


ΓòÉΓòÉΓòÉ 4. Introduction ΓòÉΓòÉΓòÉ

                          INTRODUCTION


-> For licensing information, please see License.Doc.

Thanks for evaluating NEF: a "New Echo Files" distribution
system.


ΓòÉΓòÉΓòÉ 4.1. Main Features ΓòÉΓòÉΓòÉ

                         Main Features


- It works on systems with a Binkley Style outbound and
  *.MSG or Squish message base.

- File Import/Forward/Hatch via the standard .TIC system,
  initially implemented by Tick.

- File "Areafix", to automatically link/unlink file areas via
  netmail messages. Wildcards can be used to make multiple
  link/unlink requests easier.

- Support for "FileBone.Na style" files.

- Automatic forwarding of requests for missing areas to the
  uplinks.

- Fast Squish netmail scan.

- Flexible file announcements via echo or netmail messages.
  Wildcards in file area tags allow easy configuration of
  multiple announcement areas for different groups of file
  areas.

- Full multitasking support. File sharing problems are handled
  wherever necessary.

- Full 4D operation; no direct support for ancient pointnet
  addressing method. However points addressed via pointnet can
  obviously be seen with their pointnet adress.

- Different outbounds for different domains are supported the
  same way as in Squish, via zone mapping.

- Very flexible MultiAka support. You can use different
  addresses in different areas, different addresses for
  different downlinks in the same area, etc.

- Outbound analysis and report to message areas and/or file.

- "Passthru" Area support.

- Long Description ("LDESC" keyword) support.

- Multiple "Desc" support.

- Multi-line description support for Files.Bbs.

- EchoToss.Log support.

- Automatic creation of new areas from authorized uplinks.

- Automatic linking of specified downlinks to selected new
  areas when they are automatically created.

- Check on imported description strings, to avoid trojan horses
  using certain control characters.

- Clean and compact link configuration file.

- Easy addition (on area TAG basis) of text strings at the head
  of imported descriptions, to allow inclusion of flags and
  download counters in selected areas.

- Easy partial/total area split/merge: you can forward
  certain files to a new area TAG.

- Support for Maximus 3.xx FileBase: when the file areas
  are modified the filebase is internally updated (no need for
  external FB/FBP).  The additional UniFiles.Idx (with no
  duplicates) created by QFB (my FB/FBP substitute) is also
  maintained.

- Automatic addition of new areas to the Maximus 3.xx
  configuration.

- Support for Squish configuration file, to get the
  information about path, type and primary address of message
  areas directly from it.

- (OS/2) Support for "Feature DLLs": developers can find the
  necessary Header file and an example C source included in
  the NEF package (Nefeat.H, Feature.C, Feature.Dll).


ΓòÉΓòÉΓòÉ 4.2. Credits ΓòÉΓòÉΓòÉ

                            CREDITS

"BinkleyTerm" is a trademark of Bit Bucket Software Co.

This program uses the Squish "MsgAPI" code, Copyright 1991-1994
by Lanius Corporation. "Squish" and "Maximus" are trademarks of
Lanius Corporation.

"Tick" is Copyright by Barry Geller

The archivers referred-to throughout this documentation are
Copyright and/or trademarks of the respective owners.


ΓòÉΓòÉΓòÉ 4.3. Overall Operation ΓòÉΓòÉΓòÉ

                       OVERALL OPERATION


When invoked, first of all NEF looks into the netmail area(s)
for netmail messages to the Link Robot (Areafix like) and
executes the commands required; then it looks for new .TIC files
in the netfile area(s) and forwards them.

The ingoing files are moved to their destination directory and
the description is appended to the files.bbs.

A careful check is operated on the text of the description, to
avoid trojan horses that use special control characters.

Existing old descriptions for the ingoing files are deleted.

If the Replaces field is present in the ingoing .TIC (and the
function is not disabled in NEF.CFG), the pertinent file is
erased and its description removed from the files.bbs.

The forwarded TICs will have a new Path line with UTC time of
forward and updated SeenBys; Points are not included in the
SeenBys of TICs addressed to other links, to avoid unnecessarily
huge lists of SeenBys.

The .BSY support avoids conflicts in the outbound, while
possible conflicts in the access to files.bbs are minimized by
waiting several seconds before giving up.

Finally, NEF writes the announcements of the received files;
each message is limited (before splitting) to the maximum size
specified with the "MsgSize" statement (default is 12KB to avoid
problems with old mail processors).

Conflicts on the message base are handled by the Squish MsgAPI.

When the Maximus FileBase support is enabled, a mutual exclusive
semaphore flag "FileBase.Bsy" is used to avoid concurrent access
and modification of the filebase by other ApWorks programs.
There is no need to delete this flag if it remains after a power
failure or abnormal termination (ApWorks programs are smart
enough to realize whether the flag is really in use or not).


ΓòÉΓòÉΓòÉ 4.3.1. From Address Selection ΓòÉΓòÉΓòÉ

                     From Address Selection

The algorythm to choose the "From" address for the TIC files is:

If an aka ovverride is present in the "FileArea" definition
   then use FileArea aka override
else if an aka override is present in the "FileLink" definition
   then use FileLink aka override
else if the destination zone matches an "Address" statement
   then use the zone-matching address
else
   use the primary (first) "Address" statement.


ΓòÉΓòÉΓòÉ 4.3.2. Description Handling ΓòÉΓòÉΓòÉ

                      Description Handling

The TIC files can contain "Desc" and "LDesc" lines. Usually the
description contained in "Desc" line(s) is short and
unformatted, while that carried by the "LDesc" lines is long,
multi-line and formatted.

For the announcements, the longest one is selected.

For the Files.Bbs: if MultiLineDesc support is enabled, the
longest description is used, otherwise the "Desc" one.




ΓòÉΓòÉΓòÉ 5. Installation ΓòÉΓòÉΓòÉ


                          INSTALLATION


1) There are 2 versions of NEF: OS/2 and DOS/32, distributed in
   different archives. The main program is always named NEF.EXE:
   please make sure you have the correct version.

2) Edit your Nef.Cfg.
   You can find useful examples in the NEF_*.Cfg files and
   detailed information in the "CFG REFERENCE" section of this
   documentation.

3) Edit your batch file in order to call NEF whenever you would
   like to test for the presence of .TIC files in your inbounds
   and process them. If you do not pass a different pathname as
   a command line parameter, Nef.Cfg must reside in the current
   directory.

4) (OS/2): Make sure you have the MSGAPI32.DLL in a directory
     contained in your LIBPATH and the PmHatch.Exe program in
     your PATH. MSGAPI32.DLL can be found in the Squish 1.11
     archive.

   (DOS): Make sure you have the DOS4GW.EXE Dos extender (from
     Rational System Inc.) in your path.

     The DOS4GW extender requires an XMS or DPMI memory driver
     installed in your config.sys: e.g. HIMEM.SYS, QEMM (by
     QuarterDeck Office Systems Inc.).

5) In order to have a correct UTC time specification in your
   outgoing TICs, please note that you must have the environment
   variable "TZ" correctly set in config.sys (OS/2) or
   autoexec.bat (DOS).

   E.g. for Central European Time (CET):

     SET TZ=CET-01 (winter, "normal" solar time)
     SET TZ=CET-02 (summer, daylight saving time).

   E.g. for USA East Coast:

     SET TZ=EST5EDT

     Eastern time is 5h less than UTC and Daylight saving
     applies with the "standard rule" from the first sunday o
     april to the last sunday of october.

   More complicate expressions might be used to specify
   automatic change to and back from daylight saving, if a fixed
   rule is available.

   E.g. for Italy: daylight is 1h ahead from the last sunday of
   march to the last sunday of september.

     SET TZ=CET-01CDT,M3.5.0,M9.5.0

   (See a C manual for further details).


ΓòÉΓòÉΓòÉ 6. The Command Line ΓòÉΓòÉΓòÉ


               Command Line OPTIONS and SWITCHES


To get help about the command line syntax, use the "-h" or "-?"
command line switch: type "NEF -h" or "NEF -?".

The following forms are available:

  NEF [<sw>]
  NEF [<sw>] NOTIFY [<adr> ...]
  NEF [<sw>] OUT|OUTVIEW [<file>]
  NEF [<sw>] CLEAN
  NEF [<sw>] HATCH|MATCH|CATCH|SEND
  NEF [<sw>] HATCH|MATCH|CATCH <name>[/<repl>] <TAG> [<desc>] [@DIZ]

where:

  <sw> is one or more of:

    -c<cfg>   Use <cfg> as configuration file instead of the
              default "Nef.Cfg".

              Example: "Nef -ce:\cfg\nef2.cfg"


    -d<adr>   Hatch to <adr> only.

              If you Hatch/Catch/Match/Send a file with the
              -d<adr> command line switch, it is sent to <adr>
              only.

              <adr> can be any 4D address: in the case it is
              defined as a link in the matching "FileArea" or
              even only as a "FileLink", the specified akas,
              password and switches are applied.

              If, on the contrary, <adr> is a unknown address,
              the Hold flavour is used, no password is put in
              the TIC and the "from" aka is derived from an
              aka-match on the zone.

              Example: "Nef -d2:332/589 hatch"


    -h or -?  Help.


    -k        Keep local files (do not Replace,
              for Match/Catch).


    -l<log>   Use <log> as logfile instead of the one specified
              via the "StatusLog <log>" configuration statement.

              Example: "Nef -le:\cfg\nef.log"


    -p        Clean passthru areas before terminating, see also
              the "CLEAN" option.

              Examples:

                NEF -p
                NEF -p OUT


    -t        Toggle Secure mode (see also the NoSecure cfg
              statement).


  A description of options follows:

    NOTIFY    Notify linked areas to the specified address list,
              where <adr> is a 4D address.
              If no address is given or "ALL" is specified, NEF
              will notify to all defined links.

    OUT       Outbound analysis (message output), optional
              concise output to <file> (no specification of each
              and every attached file). See the <OUT> and
              <OUTVIEW> "special tags" in the "Announce"
              section.

    OUTVIEW   Same as OUT, but optional output to <file> is
              verbose.

    CLEAN     Clean passthru areas.

              Since it might be not efficient to always scan the
              entire outbound to check for passthru files to be
              deleted, NEF must be explicitly instructed to do
              so (see also the "-p" command line switch).

              Example: "Nef Clean"

    HATCH     Traditional hatch.
    MATCH     Move file to destination area then hatch.
    CATCH     Copy file to destination area then hatch.
    SEND      (OS/2) Hatch via PM Dialog.

              If you use one of these hatch options, NEF will
              not process inbound .TICs; instead it will send
              the specified files to your links.

              Examples: "Nef Hatch"
                        "Nef Match"
                        "Nef Catch"
                        "Nef Send" (OS/2 Only)

              When no parameters are specified after the hatch
              option, your interaction is required: you will be
              requested the filename specification (Dos or OS/2
              wildcards allowed) and, for each matching file,
              the optional "replace" name, the area TAG, the
              description and the optional "Long Description".

              On the other hand, if you specify the hatch
              parameters on the command line, you cannot give a
              "Long Description" apart from that taken from the
              File_Id.Diz.

              HATCH sends the specified files; they are not
              moved and their description is not modified.

              MATCH moves the specified files to the directory
              that corresponds to the specified <TAG>, updates
              their descriptions (see "Description Handling" in
              Overall operation) and sends them as per normal
              hatch. If a <replace> file is specified, it is
              deleted with its associated description.

              CATCH is just like Match, but the files are copied
              instead of moved.

       (OS/2) SEND allows to specify all the hatch parameters
              via a user friendly PM Dialog. Please make sure
              the PmHatch.Exe file is in the PATH. In the case
              the PmHatch program terminates abnormally, the NEF
              program will wait for it indefinitely: you can
              terminate it using CTRL-C or CTRL-Break.

              See the "PmHatch" section below for further
              information.


  Parameters for Hatch/Match/Catch:

    <name>    This is the full pathname of the files you want to
              H/M/Catch. You need to specify the full path even
              if you are hatching files that reside in the
              directory corresponding to <TAG>. O.S. wildcards
              are allowed.

    <replace> This is the optional name of the file to be
              replaced: if the receiving system has this feature
              enabled, a file named <replace> in the <TAG> area
              will be deleted while importing the new file.

    <TAG>     This is the tag used for distributing an echo-file
              area.

    <desc>    This is the "short" file description and must be
              enclosed between quotes '"'.

              In the case you need to include the '"' character
              in the description, just precede it with a
              backslash escape character: '\"'.

              If you want to take this description from the
              files.bbs, you can just specify "@BBS".

              Although NEF allows not to specify any <desc>, it
              is highly recommended that a "short" description
              is supplied, even when a "long" one is used.

    @DIZ      This parameter allows to (optionally) take a
              "long" description from the File_Id.Diz contained
              in archive <name>.

              Please note that this is an additional OPTIONAL
              field, while <desc> should be MANDATORY (although
              NEF does not complain about a missing <desc>).

        Note: Please realize that the "short" and "long"
              descriptions are two separate and indipendent
              items.

              Short description: single line, "Desc" keyword in
              TIC files.

              Lond description: multiple lines, "Ldesc" keywords
              in TIC files.


ΓòÉΓòÉΓòÉ 6.1. Examples ΓòÉΓòÉΓòÉ


Examples:

    NEF Hatch d:\p\prg12.rar/prg11.rar COMMS "New comm prg"

        d:\p\prg12.rar is hatched (NOT moved) into the COMMS
        area; prg11.rar will be deleted on receiving systems.

    NEF Catch d:\p\prg12.rar/prg11.rar COMMS "New comm prg"

        d:\p\prg12.rar is copied to the directory corresponding
        to the COMMS file area and is hatched to the COMMS area.
        prg11.rar is deleted locally and will be deleted on
        receiving systems.

    NEF Match d:\p\prg12.rar COMMS "New comm prg"

        d:\p\prg12.rar is moved to the directory corresponding
        to the COMMS file area, it is hatched to the COMMS area,
        no replace information is put in the outgoing .TICs.

    NEF Send

        (OS/2) Invokes the PM dialog window.

    NEF Hatch d:\apbbs\nef999.rar APBBS @bbs

        d:\apbbs\nef999.rar is hatched into the APBBS area,
        taking the description from the files.bbs.

    NEF Hatch d:\apbbs\nef999.rar APBBS "Nef 9.99" @diz

        d:\apbbs\nef999.rar is hatched into the APBBS area,
        taking "Nef 9.99" as the "short" description and the
        File_Id.Diz (if present in the archive) as the "long"
        description.

    NEF Hatch d:\apbbs\nef999.rar APBBS @bbs @diz

        d:\apbbs\nef999.rar is hatched into the APBBS area,
        taking the "short" description from the files.bbs and
        the "long" description from the File_Id.Diz (if it is
        contained in the archive).

    NEF -d2:332/504.2 Hatch d:\apbbs\nef999.rar APBBS @bbs @diz

        Same as above, but the file is hatched to 2:332/504.2
        only.

    NEF OUT

        An outbound analysis is performed, the results are
        reported via messages in the area(s) configured in
        Nef.Cfg (see the Announce statement).

    NEF OUT Out.Txt

        Same as above, but the output is also written to
        "Out.Txt" in "concise mode".

    NEF OUTVIEW Out.Txt

        Same as above but the file output is verbose.

    NEF -p OUT

        NEF will report the status of the outbound and clean the
        passthru areas.

        If you need to maintain passthru areas, this is the most
        efficient use, since NEF must scan the outbound once to
        make two different things ("clean passthru" and
        "outbound report").

    NEF Notify
    NEF Notify All

        A notification message is sent to all the defined links,
        specifying the linked areas.

    NEF Notify 2:332/589 1:234/567

        A notification message is sent to the specified links.


ΓòÉΓòÉΓòÉ 6.2. PmHatch ΓòÉΓòÉΓòÉ

                            PmHatch

   OS/2 Only:

        To invoke the PM hatch program you must type "NEF send".
        The PmHatch program is very simple and intuitive to use:
        see the following description.

        You can select the destination Area Tag via a drop-down
        list: just click with the mouse on the button at the
        right of the entry field.

        You have three radio buttons to select the "type" of
        hatch (normal, with Copy, with Move), just as you use
        Hatch/Catch/Match from the command line.

        You can choose the file to be hatched via a file dialog
        box: just click on the "Browse" push button on the right
        of the field. The file dialog starts from the directory
        corresponding to the selected Tag, but you can move to
        any drive or directory.

        You can also specify a "Replace" file via a file-dialog
        by clicking on the "Browse" push-button on the right of
        the "Repl" field.

        When doing Copy or Move, the files.bbs of the
        destination area is updated and the "replace" file (if
        specified) is deleted, just as if the file were tossed
        from the inbound.

        You can mark the "No Local Kill" checkbox to prevent NEF
        from deleting the "replace" file in the local area.

        You can load a "short description" (Desc) from the
        files.bbs, by clicking on the "FilesBbs" push-button.

        You can load a multi-line "long description" (Long Desc)
        from the File_Id.Diz inside the archive, from the
        Files.Bbs or from a specified file (Arc Diz, FilesBbs,
        File push-buttons respectively).

        If you do not have the "CompressCfg <filename>"
        statement in Nef.Cfg, the "Arc Diz" push-button will be
        disabled.

        Of course you can always fill-in or modify any field
        manually.

        Now look at the five push-buttons at the bottom of the
        hatch dialog:

        <OK>: to exit the dialog and hatch all the entered files.

        <Prev>: to visualize the previous hatch entry.

        <Next>: to create a new (empty) entry in order to hatch
        another file or to move to next entry if <Prev> has been
        used.

        <Copy>: to copy the visualized entry to the first free
        position, in order to hatch another file by modifying
        the current entry.

        <Cancel> or ESC: to cancel the current entry.

        ALT-F4 or "Close", to abort (cancel all the hatch
        entries).



ΓòÉΓòÉΓòÉ 6.3. Errorlevels ΓòÉΓòÉΓòÉ


                          ERRORLEVELS


  0 - File areas modified: Match or .TIC processed.
  1 - File areas not modified: Hatch or NO .TIC processed.
  2 - Help requested.
  3 - Abnormal termination
  4 - Configuration file not found.
  5 - Invalid parameter on command line.
  6 - No Outbound defined in cfg file.
  7 - Disk Full.
  8 - Out of Memory.
  9 - Can't open Log file.
 10 - Prefix or Suffix too long.
 11 - User Input Error (interactive hatch/match).
 12 - TimeOut waiting for concurrent NEF process to finish.
 13 - Error while accessing .SAV file.
 17 - FileBase Busy TimeOut.

250 - MsgApi: Init Error.
251 - MsgApi: Area Open Error.


ΓòÉΓòÉΓòÉ 7. Cfg Reference ΓòÉΓòÉΓòÉ


                         CFG REFERENCE


Before analyzing the cfg keywords in detail, let's introduce the
overall mechanism that is at the basis of NEF's file forwarding
capabilities.

Each area (defined via the FileArea keyword) can be
mono-directional or bi-directional.

In bidirectional areas every link can send files to us and we
forward to everyone, unless those with a "receive-from"
override.

Monodirectional areas can be "receive from everyone" or "send to
everyone". Obviously, at least one link must have an override in
the opposite direction, unless we are the destination or
origination of all the files.

NEF uses the three flags 'I' (Input: we accept from), 'O'
(Output: we send to) and '*' (bidirectional) to define the
direction of an area or link.

Each area has a direction, that can be overridden on a per-node
basis by a global (in the FileLink statement) or local (in the
FileArea statement, before the pertinent link address) direction
override.

In other words: each link has a direction that is defined in
order of priority (from lowest to highest) by the area direction
(I|O|* in FileArea), the global link override (in the FileLink
statement), the local link override (before link address in the
FileArea statement).

It is recommended not to use the global link override when not
really useful, so that the area definition statements remain
clearly readable without the need to keep one eye on the
FileLink statements.

Usually the global link override is useful when you have an
uplink for many areas. For example: if one day the uplink and
one of the downlinks switch their role, you have to move the 'I'
flag from one FileLink statement to the other with no need to
change all the area definitions.

The area direction definition is very useful to allow automatic
linking via the Link Robot both to normal "Uplink to Downlinks"
areas and to reverse "Downlinks to Uplink" areas (mostly used
for "pre" areas to collect files and send them to the
coordinator).

As a matter of fact, in response to a link request, the Link
Robot only adds the requesting address (with no flags) to the
FileArea statement. So the real characteristics of the link
depend on the Area direction and on the link flags (FileLink
statement).



ΓòÉΓòÉΓòÉ 7.1. Conventions ΓòÉΓòÉΓòÉ


                         Conventions



- Items between square brackets (e.g. [<item>]) are optional.

- Items separated by '|' are mutually exclusive (e.g. I|O|*).

- The names of the various Keywords are NOT case sensitive.

- The area TAGs are NOT case sensitive.
  Please be aware that old TIC processors might not be able to
  handle tags longer than 8 characters or containing dots.

- <WTAG> is a "Wild TAG" specification: it can be a normal area
  TAG or contain wildcards in the "OS/2 style".

  Examples:

  "*LOC*" specifies all tags that contain "LOC".

  "FW???" specifies all tags that have up to three characters
  after "FW".

- When a directory path is required, the trailing backslash '\'
  is optional.

- The ';' character starts comments: any character following the
  ';' is ignored. Please note that configuration text strings
  (e.g. Subj, Origin) can contain the ';' character provided
  they are enclosed in quotes '"'.

- The maximum length of configuration lines (including FileArea
  definitions) is 510 characters.

- ... means that you can list further items of the same type.

- Unless differently specified, addresses are standard 4D and
  MUST begin with the zone number (FileArea statements excluded).

Please, note that the order of the configuration statements
follows some logical rule. In order not to create confusion in
the .cfg file and not to break some _necessary_ order relation,
please follow the scheme proposed in the example NEF_*.CFG files
and in this reference documentation.


ΓòÉΓòÉΓòÉ 7.2. System ΓòÉΓòÉΓòÉ

                          S Y S T E M


ΓòÉΓòÉΓòÉ 7.2.1. RegKey ΓòÉΓòÉΓòÉ


RegKey <RegKey>

        Registered Users only: <RegKey> is the registration key
        and it is NOT case sensitive.

    Example:

        RegKey dfhyuwru6274623


ΓòÉΓòÉΓòÉ 7.2.2. Address ΓòÉΓòÉΓòÉ


Address <Address>

        You can use as many Address statements as you need for
        all of your AKAs. The first one specifies the "primary"
        address. <Address> is a standard 4D address
        specification.

    Example:

        Address 2:332/504.0   ; Primary Address
        Address 2:332/524.0   ; Second line aka
        Address 2:332/500.0   ; Hub aka
        Address 9:999/999.9   ; one more aka


ΓòÉΓòÉΓòÉ 7.2.3. StatusLog ΓòÉΓòÉΓòÉ


StatusLog <LogFile>

        <LogFile> is the name of the file where all the
        operations performed by NEF will be logged, following
        the "Binkley Style".

        In multitasking environments, please be sure to use a
        file that cannot be used by other processes at the same
        time. For example: if (in your system) NEF can be
        executed while Binkley is running, please use different
        log files.

        Multiple NEF processes using the same config file
        (and therefore the same <LogFile>) will have no problem
        since NEF does not begin operations until the previous
        launched instance (if it uses the same .cfg file) has
        finished.

        Should you not want the log file, you can comment this
        keyword out.

    Example:

        StatusLog d:\bbs\log\nef.log


ΓòÉΓòÉΓòÉ 7.2.4. EchoTossLog ΓòÉΓòÉΓòÉ


EchoTossLog <filename>

        When NEF writes announcements into echoareas defined
        with the "AreaTag" statement, it writes the
        corresponding TAGs (one per line) to <filename>.

        If you use the "MaxPrm" statement (or MAXIMUS
        environment variable), "EchoTossLog" is not necessary
        and becomes an override of the echotosslog specification
        found in the Maximus .PRM file.

        If you do not like this output, you can override with
        the NUL name: "EchoTossLog NUL".

    Example:

        EchoTossLog d:\bbs\squish\echotoss.log


ΓòÉΓòÉΓòÉ 7.2.5. NetFile ΓòÉΓòÉΓòÉ


NetFile <InboundDir>

        You can specify as many NetFile statements as you need,
        one for each inbound directory where NEF must look for
        new .TIC files.
        <InboundDir> is the pathname of the inbound directory.

    Example:

        NetFile c:\file\net


ΓòÉΓòÉΓòÉ 7.2.6. Outbound ΓòÉΓòÉΓòÉ


OutBound <RootPath> [<Zone>]

        The outbound directories are specified with the same
        method as in squish.cfg.
        <RootPath> should not have an extension.

        The first OutBound statement does not have the <Zone>
        field and specifies the directory where NEF will build
        file attaches for the zone of the primary address.

        Subsequent OutBound statements must have the <Zone>
        field (Decimal). File attaches for the specified <Zone>
        are built in <RootPath>.<###>, where <###> is a 3 digit
        extension representing the zone number (hexadecimal).

        File attaches for zones different from the primary one
        and not matching any <Zone> of the OutBound statements
        are built in <RootPath>.<###>, where <RootPath> is the
        one specified in the first OutBound statement and <###>
        is a 3 digit extension representing the hexadecimal
        zone number.

    Note:

        The "OutBound" statements MUST be preceded by the
        "Address" ones.

    Example:

        OutBound c:\out\fidonet
        OutBound c:\out\amiganet 39
        OutBound c:\out\amiganet 40

        FileAttaches will be built in:
        Primary zone -> c:\out\fidonet
        zone 39      -> c:\out\amiganet.027
        zone 40      -> c:\out\amiganet.028
        other zones  -> c:\out\fidonet.<###>
                        where <###> is the 3 digit hexadecimal
                        representation of the zone number


ΓòÉΓòÉΓòÉ 7.2.7. TicHold ΓòÉΓòÉΓòÉ


TicHold <TicDir>

        This specifies the directory that holds all the .TIC
        files addressed to downlinks until they are sent and
        erased.

    Example:

        TicHold c:\file\tichold


ΓòÉΓòÉΓòÉ 7.2.8. BusyFlag ΓòÉΓòÉΓòÉ


BusyFlags

        This enables the Binkley-Style .BSY support.

        When attaching a file to a node, the presence of an
        appropriate .BSY file is checked; if it is present, some
        other process may be working on the same node, so NEF
        saves the attach info to a private <config>.SAV file
        (i.e. NEF.SAV when NEF.CFG is the config file). On
        subsequent runs, NEF will look for a <config>.SAV file
        and use the information in it to attempt again the
        creation of the file attaches.
        If the .BSY file is not found, it is created, the file
        attach is built, then the .BSY is erased.
        The name of the .BSY file is the same as a file attach
        to the same node: only the extension changes.

    Warning: The .BSY method has a nasty drawback: if the
        process that has created a .BSY file hangs or is
        shutdown abruptly, the .BSY file remains in its outbound
        directory, so that no other process will gain access to
        that node until somebody erases the .BSY file.
        It is advisable to delete *.BSY from the most used
        outbound directories at startup (in autoexec.bat (Dos)
        or startup.cmd (OS/2)).


ΓòÉΓòÉΓòÉ 7.2.9. NoRaidBeforeHatch ΓòÉΓòÉΓòÉ


NoRaidBeforeHatch

        Skips the scanning of netmail before the execution of
        hatch commands. This might be useful to avoid delays
        with huge *.MSG areas.


ΓòÉΓòÉΓòÉ 7.2.10. MsgSize ΓòÉΓòÉΓòÉ


MsgSize <bytes>

       To specify the maximum size (in bytes) for a message
       generated by NEF (minimum 8KB, default 12KB).

       Usually a larger message size is useful to avoid too many
       messages in reports of filebone availability. Anyway,
       please be careful not to use a size larger than your
       downlinks can handle.

       Example:

       MsgSize 90000


ΓòÉΓòÉΓòÉ 7.2.11. TicAreaCfg ΓòÉΓòÉΓòÉ


TicAreaCfg <filename>

        This defines the name of the file that contains all the
        file area definitions. See the "FileArea" keyword below
        for a description of the syntax.

        This keyword is optional: if you omit it, you can define
        your file areas directly in the .cfg file, provided you
        put all the FileArea statements _after_ the FileLink
        ones, at the end of the .cfg file.

        For systems with few areas the one-file configuration is
        handy, for systems with many areas and links, the
        separate file solution is recommended.

        Please note that the TicAreaCfg file can contain
        FileArea statements and comments ONLY.

    Example:

        TicAreaCfg d:\bbs\nef\ticarea.cfg


ΓòÉΓòÉΓòÉ 7.2.12. CompressCfg ΓòÉΓòÉΓòÉ


CompressCfg <filename>

  (OS2) To allow the extraction of File_Id.Diz while using the
        Pm Hatch.

        <filename> must specify the location and name of a
        "Squish style" compress definition file.

        In the case you are using a case-sensitive
        de/compression program (e.g. OS/2 ZIP/UNZIP), please
        make sure to use the correct switches in <filename>.

        If you are already using Squish and or Maximus, you
        can just specify the name of their compress.cfg (but do
        check that they indicate the necessary switches to avoid
        case sensitiveness during extraction).

        Refer to the "Compress Definition File" section at the
        end of this reference for the syntax of this
        configuration file.

    Example:

        CompressCfg c:\squish\compress.cfg


ΓòÉΓòÉΓòÉ 7.2.13. Squish Support ΓòÉΓòÉΓòÉ

                    Optional Squish Support


ΓòÉΓòÉΓòÉ 7.2.13.1. SquishCfg ΓòÉΓòÉΓòÉ


SquishCfg <filename>

        It is used to specify the squish configuration file, so
        that NEF can automatically get the path, type (SDM vs
        Squish) and primary address for the announcement areas
        defined with the "AreaTag" statement.

        When SquishCfg is defined, if you use "AreaTag <Tag>" to
        define announcement areas, the "FromNode <adr>"
        statement is only used to override the primary address
        specified for that area in Squish.Cfg (including the
        -p<address> overrides).

        NEF supports the "Include" keyword of Squish.Cfg: just
        be sure to always use the full pathname in the Include
        statement if NEF and Squish run from different paths.

        Both echomail and netmail areas are recognized by their
        Squish tags.

        Netmail areas will have the Private attribute and no
        origin by default. Local overrides are still possible
        via local "Origin" and "Attr" statements.

    Example:

        SquishCfg c:\squish\squish.cfg


ΓòÉΓòÉΓòÉ 7.2.14. Maximus 3.xx Support ΓòÉΓòÉΓòÉ

                 Optional Maximus 3.xx Support


ΓòÉΓòÉΓòÉ 7.2.14.1. MaxPrm ΓòÉΓòÉΓòÉ


MaxPrm <filename>

        If the MAXIMUS environment variable is defined, this
        statement is an optional override only.

        It is used to take the default for EchoTossLog and to
        get the name and location of the files necessary for
        filebase updating. The ".prm" extension in <filename>
        can be omitted.

    Example:

        MaxPrm d:\bbs\max\max.prm


ΓòÉΓòÉΓòÉ 7.2.14.2. MaxAreaAdd/MaxAreaCompile ΓòÉΓòÉΓòÉ


MaxAreaAdd <fileareactl> <lev[/keys]> <acs> [<division>]
MaxAreaCompile <command>

       NEF is able to add new (created) areas to the Maximus
       filearea.ctl or equivalent.


       <fileareactl> is the fully qualified name of the Maximus
       file-area definition file.

       <lev[/keys]> protects areas of higher privilege from
       being automatically added to the Maximus configuration.
       The level and keys are to be compared to those of
       ProtArea statements and FileBone-format files.

       <acs> is the Maximus access string to be used in
       <fileareactl> for the new area.

       <division> is the optional specification of a division
       where you want to put new areas. If not specified or not
       found, the new areas will be appended at the end of
       <fileareactl>.

       <command> is an external command to be executed before
       NEF ends, from the Maximus system directory.
       It should be used to compile the new Maximus
       configuration via SILT/SILTP.


       The area name is taken equal to the area TAG, with dots
       changed to underscores.

       The area description is taken from the FileBone-format
       files if available, otherwise it is taken equal to the
       area TAG.


       Example:

       MaxAreaAdd d:\max\filearea.ctl 0 Transient Tic.New
       MaxAreaCompile siltp max -a -2a

       The new areas, will be inserted at the end of division
       "Tic.New" in the file "d:\max\filearea.ctl", with an
       access string of "Transient". Areas with protection level
       above 0 or any protection key will NOT be added to
       maximus configuration.

       Before terminating, NEF will invoke the SILTP compiler to
       update the area configuration. The command will be
       executed after changing the current directory to the
       Maximus system one (probably d:\max\).



ΓòÉΓòÉΓòÉ 7.2.14.3. FileBaseUpdate ΓòÉΓòÉΓòÉ


FileBaseUpdate

        Requires the MAXIMUS environment variable or the
        "MaxPrm" statement _before_ in the cfg.

        NEF will automatically update the filebase for all the areas
        changed when tossing/hatching new files. No more need to
        run external FBP (FB).

    Example:

        FileBaseUpdate


ΓòÉΓòÉΓòÉ 7.2.14.4. UniqueDmpLine ΓòÉΓòÉΓòÉ


UniqueDmpLine

        Makes NEF generate FILES.DMP filebase files with
        descriptions on one line only (multiple lines are
        concatenated).

        By default, NEF outputs multi-line descriptions without
        changes to FILES.DMP: when using L)ocate and N)ewfiles
        commands, Maximus will respect the original formatting,
        but the continuation lines will be aligned to the left.

        When this statement is used, the original formatting of
        descriptions is lost (in the filebase) but Maximus will
        be able to word-wrap and align when executing L)ocate or
        N)ewfiles commands.


ΓòÉΓòÉΓòÉ 7.3. Tic Processing ΓòÉΓòÉΓòÉ



                         TIC Processing


ΓòÉΓòÉΓòÉ 7.3.1. NoSecure ΓòÉΓòÉΓòÉ


NoSecure

        Disables the secure mode.

        When "NoSecure" is used, NEF will toss incoming files
        ignoring errors due to missing password, password
        mismatch and missing from-authorization (sender not
        linked, sender receive only).

        You can also use the "-t" command line switch to toggle
        between Secure and NoSecure modes.

        Anyway the error will be noted in the logs and <BAD>
        message report (see Announce statement).

    Example:

        NoSecure


ΓòÉΓòÉΓòÉ 7.3.2. NoReplace ΓòÉΓòÉΓòÉ


NoReplace <WTAG> ...

        Multiple statements can be used.
        The specified <WTAG>s indicate in which areas you do not want
        NEF to delete files specified by the "Replaces" keyword in
        inbound TICs.

    Example:

        NoReplace *     ; to avoid Replace in all areas


ΓòÉΓòÉΓòÉ 7.3.3. CheckCRC ΓòÉΓòÉΓòÉ


CheckCRC

        This enables the CRC check of ingoing .TICs.
        If an ingoing .TIC has the CRC keyword, the specified
        CRC is checked against that of the relative file and an
        error is reported in case of mismatch.
        Outgoing .TICs will have the CRC only if it is present
        in the ingoing one.
        TICs originated by NEF (various Hatch modes) will always
        have the CRC keyword.


ΓòÉΓòÉΓòÉ 7.3.4. Touch ΓòÉΓòÉΓòÉ


Touch

        Ingoing files are "touched" while being moved to their
        destination directory (i.e. their timestamps are set to
        NOW, so that they will be seen as new files by all the
        utilities that use the file date-time to compute the age
        of files).

    (OS/2)
        When the files are touched in HPFS, the creation date is
        modified, not the modification one, in order to make the
        files recognized as new by Maximus and FLM (my File List
        Manager) without changing the date that is normally
        shown and transferred: you "see" and transfer to your
        downlinks the original date of the file while Maximus
        and FLM are able to realize that the file is new.

    (DOS & OS/2 FAT)
        Warning: The original file timestamp is lost and the
        downlinks will receive the forwarded files with the new
        timestamps.


ΓòÉΓòÉΓòÉ 7.3.5. MultiLineDesc ΓòÉΓòÉΓòÉ


MultiLineDesc <nnn> [<c>]

        By default, files.bbs description must be on a single
        line; this statement enables Multi-Line support.

        <nnn> is the number of spaces that must precede the
        continuation lines.

        <c> is the continuation character.

        If <c> is NOT specified, it is assumed that the
        continuation lines must be preceded by <nnn> spaces.

        If <c> IS specified, it is assumed that the continuation
        lines must be preceded by <nnn> spaces, the <c>
        character and one more space.

        For example, to have the 2nd and following description
        lines in files.bbs start at the 32nd column, use:

        MultiLineDesc 31


        A description in files.bbs would be like:

        Test.Zip This is the first description line
                                       this is the 2nd line
                                       this is the 3rd line
        ^                             ^^
        1                           31  32

        To have the continuation lines preceded by a '|'
        character, use:

        MultiLineDesc 29 |


        A description in files.bbs would be like:

        Test.Zip This is the first description line
                                     | this is the 2nd line
                                     | this is the 3rd line
        ^                           ^  ^
        1                          29  32


ΓòÉΓòÉΓòÉ 7.3.6. NewAreasPath/NewAreasFrom ΓòÉΓòÉΓòÉ



NewAreasPath <path>
NewAreasFrom <address> [-0] [#<aka>] [<path>]

        <path> is the base directory for new file areas
        automatically created by NEF on reception of .TICs with
        unknown area TAGs.

        <address> is a 4D address that must be enabled to
        automatically create new areas.

        -0 (zero) specifies that areas created by <address> must
        be PassThru.

        <aka> is the optional from-address to be used by NEF in
        outgoing .TICs for the areas automatically created by
        <address>.

        The <path> in "NewAreasFrom" is an override for the
        default specified in "NewAreasPath".

        Any number of NewAreasFrom statements can be used.

        While adding new areas, NEF will NOT re-order the
        existing ones, anyway it will respect an existing
        alphabetical order.

    Example:

        NewAreasPath c:\file
        NewAreasFrom 2:331/110
        NewAreasFrom 9:1/1 #9:999/999.9
        NewAreasFrom 9:2/2 -0 d:\fido\passthru\

        Let's suppose we have received a .TIC for area NEWAREA,
        which is not currently defined:
        - if it is coming from an address different from
          2:331/110, 9:1/1 and 9:2/2 -> an error is reported.
        - if it is coming from 2:331/110 -> a new area is
          created with path c:\file\NEWAREA.
        - if it is coming from 9:1/1 -> a new area is created
          with path c:\file\NEWAREA and it is configured so that
          NEF will use 9:999/999.9 (which must be an aka
          previously defined in an Address statement) as the
          from-address for outgoing .TICs.
        - if it is coming from 9:2/2 -> a passthru area is created
          with path d:\fido\passthru\NEWAREA.


ΓòÉΓòÉΓòÉ 7.3.7. DescStart ΓòÉΓòÉΓòÉ


DescStart "<string>" <WTAG> [<WTAG> ...]

        This allows to add <string> at the head of files.bbs
        descriptions while tossing files from area TAGs that
        match one of the <WTAG> specifications.

        This statement is useful for people using download
        counters and/or maximus flags for free download.

    Example:

        DescStart "/bt [00] " 1* 2*

        This adds "/bt [00] " at the head of files.bbs
        descriptions while tossing files from areas whose TAG
        begins with '1' or '2'.


ΓòÉΓòÉΓòÉ 7.3.8. TagFwd ΓòÉΓòÉΓòÉ


TagFwd <OrgTag> <FwdTag> <FileSpec> [<FileSpec> ...]

        This allows to forward files from an area to another.

        <OrgTag> and <FwdTag> are area TAGs.
        <FileSpec> is a file specification that accepts the OS/2
        style wildcards (?,*).

        All ingoing files of area <OrgTag> which match one of
        the <FileSpec>s are forwarded to area <FwdTag>.
        This way you can split or merge areas.

    Example:

        TagFwd 1-Comm Bbs AC*n prova.*
        TagFwd 1-Data bbs *
        TagFwd 1-DITO BBS *
        TagFwd 1-Comm BBO *
        TagFwd ISNMAIN POINTLST ptlist.* ptdoc.*

        Files AC*n and prova.* coming from area 1-Comm and all
        the files coming from 1-Data and 1-DITO are forwarded to
        area BBS.

        All the files from 1-COMM are also forwarded to area
        BBO.

        Files ptlist.* and ptdoc.* from area ISNMAIN are
        forwarded to area POINTLST.


ΓòÉΓòÉΓòÉ 7.3.9. FeatureLoad/Feature ΓòÉΓòÉΓòÉ


FeatureLoad <DllName>

        (OS/2) Loads a "Feature" DLL, to allow third party
        extensions to NEF.

        <DllName> can be a simple filename without extension
        (".DLL" implied) if the DLL is in the LibPath, otherwise
        a fully qualified filename (extension included) can be
        specified.

Feature <cfgline>

        (OS/2) Allows to specify configuration statements that
        are to be parsed by the DLL loaded with the previous
        FeatureLoad.

    Note:
        Multiple FeatureLoad statements are allowed, in which
        case the Feature statements refer to the last loaded
        DLL.

    Example:

        FeatureLoad MyDll
        Feature CfgItem1 "This is Item 1"
        Feature CfgItem2 "This is Item 2"


ΓòÉΓòÉΓòÉ 7.4. Tic Announcements ΓòÉΓòÉΓòÉ


                       TIC Announcements


Each announcement area is defined by a dedicated group of
statements. Many of these statements can be used before the
first announcement area definition to establish defaults to be
used in all subsequent area definitions, thus avoiding the need
to unnecessarily repeat common statements.


ΓòÉΓòÉΓòÉ 7.4.1. Global Keywords ΓòÉΓòÉΓòÉ

                        Global Keywords

=== Statements that can be used before area definitions to set
=== defaults (please note that all these statements can be
=== overridden in each area definition).


ΓòÉΓòÉΓòÉ 7.4.1.1. FromNode ΓòÉΓòÉΓòÉ


FromNode <address>

        This specifies the 4D address to be used as the
        from-address in the announcement messages: it is used in
        the header, in the Origin and in the MSGID. Usually, it
        should be your primary address.

    Example:

        FromNode     2:332/504.0


ΓòÉΓòÉΓòÉ 7.4.1.2. ToNode ΓòÉΓòÉΓòÉ


ToNode <address>

        This specifies the 4D address to be used as the
        to-address in the announcement messages: it is used in
        the header. Usually, for echo area announcements, it
        should be the same as in FromNode.

    Example:

        ToNode       2:332/504.0


ΓòÉΓòÉΓòÉ 7.4.1.3. From ΓòÉΓòÉΓòÉ


From <name>

        This specifies the name to be used as the from-name in
        the announcement messages. Usually it should be the
        SysOp name.

    Example:

        From         Alberto Pasquale


ΓòÉΓòÉΓòÉ 7.4.1.4. To ΓòÉΓòÉΓòÉ


To <name>

        This specifies the name to be used as the to-name in the
        announcement messages. Usually it should be "All".

    Example:

        To           All


ΓòÉΓòÉΓòÉ 7.4.1.5. Subj ΓòÉΓòÉΓòÉ


Subj <subject>

        This specifies the string to be used as the subject in
        the announcement messages.

    Note:

        If the Subj text contains the ';' character, it MUST
        be enclosed in quotes '"', otherwise NEF will take the
        ';' as the start of a comment.

    Examples:

        Subj    New Echo Files
        Subj    "New files; OS/2 BBS"


ΓòÉΓòÉΓòÉ 7.4.1.6. Attr ΓòÉΓòÉΓòÉ


Attr [P][K][C|H|D|N|O]

        This specifies the attributes to be used in the
        announcement messages. Usually no special attribute is
        necessary, except for private announcements in the
        netmail area.

        The available attributes are:
        P -> Private
        K -> Kill/Sent
        C -> Crash
        H -> Hold
        D -> Direct (equivalent to "CH")
        N -> Normal (default)
        O -> Normal (default)

        The required attributes can be listed in any order and
        are not case sensitive.

    Examples:

        Attr            ; no attributes
        Attr N          ; no attributes (Normal flavour)
        Attr PK         ; Private and Kill/Sent
        Attr PC         ; Private and Crash
        Attr PDK        ; Private, Direct, and Kill/Sent


ΓòÉΓòÉΓòÉ 7.4.1.7. HighAsciiOk ΓòÉΓòÉΓòÉ


HighAsciiOk

        Grants permission for High Ascii codes (> 127) in file
        descriptions.


ΓòÉΓòÉΓòÉ 7.4.1.8. Prefix ΓòÉΓòÉΓòÉ


Prefix <filename>

        This specifies the file containing the prefix text for
        announcement messages: it is put by NEF at the head of
        the message body, just before the real announcement
        lines. It should usually contain something like "New
        Echo Files Received:".

    Example:

        Prefix       d:\bbs\nef\PREFIX.NEF


ΓòÉΓòÉΓòÉ 7.4.1.9. Suffix ΓòÉΓòÉΓòÉ


Suffix <filename>

        This specifies the file containing the suffix text for
        announcement messages: it is put by NEF at the end of
        the message body, just before the tear-line and the
        Origin. It should usually contain something like "File
        Request open to everybody between 06:00 and 23:00 GMT".

    Example:

        Suffix       d:\bbs\nef\SUFFIX.NEF


ΓòÉΓòÉΓòÉ 7.4.1.10. Origin ΓòÉΓòÉΓòÉ


Origin <origin>

        This specifies the text to be used as the Origin in
        announcement messages. NEF will add the required " * "
        at the head and the address at the end, truncating
        <origin> if necessary to fit the 79 character maximum
        length.
        To disable the Origin (e.g. in netmail area) use an
        empty origin string.

    Note:

        If the Origin text contains the ';' character, it MUST
        be enclosed in quotes '"', otherwise NEF will take the
        ';' as the start of a comment.

    Examples:

        Origin       <ApWorks Modena I><Tel.[phone]>
        Origin       "ApWorks Modena I; [phone]/3"
        Origin       ; empty origin to disable origin generation


ΓòÉΓòÉΓòÉ 7.4.2. Area Definition ΓòÉΓòÉΓòÉ

                        Area Definition

=== All the preceding statements can be used both before
=== announcement area definitions (to set defaults) and inside
=== each definition to override the defaults.


ΓòÉΓòÉΓòÉ 7.4.2.1. AreaTag/AreaPath ΓòÉΓòÉΓòÉ


AreaTag <Tag> [<path> [-$]]
AreaPath <path> [-$]

        One of these statements starts the definition of an
        announcement area.

        <Tag> is the area TAG, to be logged to EchoTossLog
        provided this is not a NetMail area.

        <path> is the directory for the *.MSG format or the full
        filename (no extension) for the Squish base.

        -$ specifies the use of the Squish format.


    AreaTag <Tag>

        This is the form to be generally used when SquishCfg is
        defined.

        NEF will look-up the <Tag> in SquishCfg to find the
        corresponding path, message-base type and primary
        address.

        A local "FromNode" statement can be used to override the
        primary address for the area (including -p<address>
        specifications) found in SquishCfg.

        If this is an EchoArea, its <Tag> will be output to
        the EchoTossLog whenever NEF writes to this area.

        If this is a NetArea, as a default, the Origin will not
        be used and the Private attribute will be set; you can
        override this with local "Origin" and "Attr" statements.


    AreaTag <Tag> <path> [-$]

        This is the form to be used for EchoMail areas when
        SquishCfg is not defined or you want to override its
        information AND you want <Tag> to be logged to
        EchoTossLog.


    AreaPath <path> [-$]

        This is the form to be used when SquishCfg is not
        defined AND you do not need to log a <Tag> to
        EchoTossLog (NetMail areas or no EchoTossLog defined).

    Notes:

        Any of the statements described above in this "Tic
        Announcements" section can be used after the
        AreaTag/AreaPath statement to override the defaults for
        this announcement area only.

        Please note that you can use different AreaTag/AreaPath
        definitions with the same message area Tag/Path, in order to
        announce different file areas in different messages but
        in the same message area.

    Examples:

        AreaTag OS2BBS
        AreaTag OS2BBS d:\bbs\mail\os2bbs -$
        AreaPath d:\bbs\mail\net


ΓòÉΓòÉΓòÉ 7.4.2.2. Announce/NoAnnnouce ΓòÉΓòÉΓòÉ


Announce <WTAG> [<WTAG> ...]
NoAnnounce <WTAG> [<WTAG> ...]

        This defines the list of file areas to be announced in
        the current announcement message area (the one defined
        by the previous AreaTag/AreaPath statement).

        Multiple statements are allowed.

        All the TAGs that match one of the <WTAG>s in "Announce"
        and do not match any of the <WTAG>s in "NoAnnounce" are
        announced in the current area.

        Obviously you can omit the "NoAnnounce" statement if you
        do not need to exclude areas that have been included via
        the "Announce" statement.

        "Announce *" makes all the file areas announced.

    Special tags:

        The following "special tags" can be used in "Announce"
        or "NoAnnounce" statements as if they were normal area
        TAGs, but are not included in the "*" wildcard (i.e.
        "Announce *" does not make them announced).

        "<BAD>" is used to announce all the TICs that have been
        processed with some error.

        "<DEF>" is used to announce all the files that have not
        been announced elsewhere. A separate announcement is
        generated after all other announcements have been
        completed, even if "<DEF>" is listed together with other
        TAGs.

        "<OUT>" is used to make a concise outbound report when
        the OUT or OUTVIEW command line option is used.
        Subj, Prefix and Suffix are ignored.

        "<OUTVIEW>" is used to make a detailed outbound report
        when the OUT or OUTVIEW command line option is used.
        Subj, Prefix and Suffix are ignored.

        "<THRU>" represents all passthru areas. If you want to
        keep NEF from announcing files received in PassThru
        areas, just use "NoAnnounce <THRU>".

    Examples:

        Announce UTILNET SOFTDIST SDS*
        NoAnnounce SDSOTH <THRU>

        This announces the file areas with tag "UTILNET",
        "SOFTDIST" and all those whose TAG starts with "SDS" but
        not "SDSOTH" or passthru areas.

        Announce PRIVFILE <BAD> <DEF>

        This announces area "PRIVFILE" and all the TICs that
        have been processed with errors; at the end, in a
        separate message, it announces the files that have not
        been announced elsewhere.

        Announce SPECIAL <OUT>

        This announces the file area with tag "SPECIAL"; at the
        end, in a separate message, it creates a concise report
        of the outbound.

        Announce SPECIAL <OUTVIEW>

        This announces the file area with tag "SPECIAL"; at the
        end, in a separate message, it creates a verbose report
        of the outbound.


ΓòÉΓòÉΓòÉ 7.4.3. Announce example ΓòÉΓòÉΓòÉ


    Complete example of the announcement definition section,
    SquishCfg defined:

----------------------------------------------------------------

  ; Defaults definition

    FromNode     2:332/504.0
    ToNode       2:332/504.0
    From         Alberto Pasquale
    To           All
    Subj         New Echo Files
    Attr
    Prefix       PREFIX.NEF
    Origin       ApWorks Modena I ([phone]/3)
    Suffix       SUFFIX.NEF

  ; Announcement areas: each statement is local to the preceding
  ; AreaTag and overrides the default one.

    AreaTag      APWORKS
    Announce     APBBS*
    Prefix       RelPre.NEF
    Subj         New ApWorks files

    AreaTag      OS2BBS
    Announce     APBBS*
    NoAnnounce   *DOS*
    Prefix       RelPre.NEF
    Subj         New APBBS files

    AreaTag      NETMAIL
    Announce     <OUTVIEW> <DEF>
    From         NEF
    To           Alberto Pasquale
    Subj         Not Announced Elsewhere
    HighAsciiOk

    AreaTag      NETMAIL
    Announce     <BAD>
    From         NEF
    To           Alberto Pasquale
    ToNode       2:332/504.1
    Subj         Processed with Errors

----------------------------------------------------------------

    Complete example of the announcement definition section,
    SquishCfg NOT defined:

----------------------------------------------------------------

  ; Defaults definition

    FromNode     2:332/504.0
    ToNode       2:332/504.0
    From         Alberto Pasquale
    To           All
    Subj         New Echo Files
    Attr
    Prefix       PREFIX.NEF
    Origin       <ApWorks Modena I><Tel.[phone]>
    Suffix       SUFFIX.NEF

  ; Announcement areas: each statement is local to the preceding
  ; AreaPath and overrides the default one.

    AreaTag      SWN_332.500 d:\msg\swn -$
    Announce     UTILNET
    Subj         UTILNET file news

    AreaTag      SWN_332.500 d:\msg\swn -$
    Announce     FIDONEWS SDS* ECHO-* FTSC NEWSLETR SOFTDIST
    NoAnnounce   ECHO-R*
    Subj         SDS/NEWS file news

    AreaPath     d:\msg\net -$    ; Netmail to the SysOp
    Announce     NODE* POINTLST <BAD> <DEF> <OUTVIEW>
    From         NEF
    To           Alberto Pasquale
    ToNode       2:332/504.1
    Subj         Reserved file news
    Attr         PK      ; This must be private and kill/sent
    Origin               ; No Origin for netmail !

----------------------------------------------------------------


ΓòÉΓòÉΓòÉ 7.5. FileFix Link Robot ΓòÉΓòÉΓòÉ



                       FileFix Link Robot


It's the traditional "Raid" or "TicFix" function: it allows
downlinks (but also special uplinks) to link/unlink file areas
via a netmail message.

The message should have the agreed password as the subject,
possibly followed by some switch.
The required password is that defined in the "FileLink"
statement described below.

The body of the message contains the commands.
There can be several commands on a single line provided they are
separated by blanks.

Password, switches and commands are case insensitive.

Switches that can be used in the subject, after the password,
only the _first_ letter is required (and checked):

    -Help           Help.
    -Query          List all areas (linked and available).
    -Linked         List linked areas.
    -Unlinked       List unlinked areas.


The commands available for the message body are:

    [+]<WTAG>
        Links all the areas whose TAG matches <WTAG>.
        The '+' character is optional (useful in the case <WTAG>
        starts with the '-' character).

    -<WTAG>
        Unlinks all the areas whose TAG matches <WTAG>.

    %Help        same as -h
    %Query       same as -q
    %List        same as -q
    %Linked      same as -l
    %Unlinked    same as -u


Example:

        From: John Doe of 2:332/580.0
        To:   Nef      of 2:332/504.0
        Subj: Secret -H
        -----------------------------
        %Query
        1* -1-COMM
        +2*
        -2-WINDOW
        ---

        The Help and Query commands are invoked, all areas whose
        tag begins with '1' are linked, area "1-COMM" is
        unlinked, all areas whose tag begins with '2' are linked
        and area "2-WINDOW" is unlinked.

Notes:  The actual order of command execution is based on the
        area definition order. NEF scans the defined areas from
        the first to the last one only once, applying for each
        area all the pertinent commands.

        If a link in a FileArea statement is not properly
        defined in a FileLink one, it is removed when the
        Link Robot re-writes that FileArea statement in
        execution of an Add or Delete command.

        While re-writing areas, the Link Robot will NOT re-order
        the links. However it will respect an existing order
        while adding new links.

        If Area aka overrides are used, they are reported by
        Area-List commands.


ΓòÉΓòÉΓòÉ 7.5.1. AutoLink ΓòÉΓòÉΓòÉ



AutoLink <name>

        The robot will answer to the messages addressed to one
        of the addresses defined in the "system" section and to
        one of the names defined in the AutoLink statements.
        You can use as many AutoLink statements as you need to
        define all the akas you like.
        If no AutoLink statement is used, then the Link Robot is
        disabled.

    Example:

        AutoLink NEF
        AutoLink Raid
        AutoLink TicFix


ΓòÉΓòÉΓòÉ 7.5.2. NetMail ΓòÉΓòÉΓòÉ


NetMail <path> [-$] [-p<adr>]

        This defines a netmail area to be searched for messages
        addressed to the robot. You can use as many NetMail
        statements as you need.

        The optional -$ indicates a Squish format area.

        The optional "-p<adr>" specifies the primary (default)
        address for the area.

        When multiple NetMails are defined, NEF needs <adr> to
        choose (via zone matching) the right area where to write
        the messages addressed to the FileBone's "FileFix" robot.

        Usually all but the first netmail statements should
        contain a primary address specification.

        Note: when a Squish base is used, a pointer to the last
        scanned message is stored in <path>.NEF, so that next
        scan will consider new messages only.

    Example:

        NetMail d:\msg\fidonet -$              ; default netmail area
        NetMail d:\msg\os2net  -$ -p89:456/789 ; OS2Net netmail area


ΓòÉΓòÉΓòÉ 7.5.3. KillReceived ΓòÉΓòÉΓòÉ



KillReceived

        This keyword instructs NEF to kill messages addressed to
        the Link Robot after the execution of the contained
        commands. When commented out, the messages are marked as
        received instead of being erased.


ΓòÉΓòÉΓòÉ 7.5.4. AreaDescWrap ΓòÉΓòÉΓòÉ


AreaDescWrap <indent> <right>

        The descriptions returned by the "FileFix" functions
        will be word-wrapped so that continuation lines start
        with <indent> spaces and do not exceed column <right>.

    Example:

        AreaDescWrap 25 79


ΓòÉΓòÉΓòÉ 7.5.5. HelpFile ΓòÉΓòÉΓòÉ


HelpFile <filename>

        This keyword defines the file to be put into the Link
        Robot's answer in reply to a Help request.

        Usually this file contains instructions for using the
        Link Robot.

    Example:

        HelpFile d:\bbs\nef\NefHelp.Txt


ΓòÉΓòÉΓòÉ 7.5.6. ProtArea ΓòÉΓòÉΓòÉ


ProtArea <WTAG> <level>[/<keys>]

        This keyword allows to selectively protect areas from
        automatic linking. Unlinking is always possible.

        The protection scheme is based on the traditional
        combination of level and keys.

        <WTAG>  specifies the TAG or group of TAGs to be
                protected.
        <level> is an integer number in the range 0-65535.
        <keys>  is a subset of the following 32 element set:
                {12345678ABCDEFGHIJKLMNOPQRSTUVWX}
                These keys are case insensitive.

        When processing an area TAG, NEF scans the ProtArea
        statements from the first one to the last one: the first
        matching <WTAG> determines the protection level and
        keys. If no match is found, <level> is assumed to be the
        maximum and <keys> the full set of available keys, so
        that the area gains maximum protection.

        Usually it's convenient to override the default maximum
        protection so that you can list only a few special areas
        with their protection level and keys while letting all
        the others get a default NULL protection (automatic
        linking for everybody). To accomplish this result, you
        can use a "ProtArea * 0" as the last ProtArea statement.

        Please, note that the order of the ProtArea statements is
        _essential_, since they area scanned from the first one
        to the last one in search for a match between the TAG in
        examination and the <WTAG> of the ProtArea statements.

    Example:
        ProtArea PRIVATE  1000/12ABC  ; Protected private area

        ProtArea 1*       100/P       ; Areas starting with '1'
                                      ; are not for everybody.

        ProtArea *        0           ; The remaining areas are
                                      ; for everybody.


ΓòÉΓòÉΓòÉ 7.5.7. FileBone Support ΓòÉΓòÉΓòÉ


                        FileBone Support


NEF is able to use information distributed via the FileBone.Na
and FileBone.No files.

Many useful functions are allowed by the use of these files, so,
even if you do not receive them from your uplink, you could
evaluate the possibility of creating "FileBone-style" files on
your own, just to store some information that can be retrieved
by NEF.

When FileBone-style files are used:

- The Query command reports the areas available on the FileBone,
  in addition to those that are not linked to the downlink but
  already available on the local system.

- Area descriptions can be returned by FileFix commands.

- Level and Keys protect areas from "FileFix" linking.
  A node is entitled to add an area only if it has level and
  keys that match the requirements from BOTH the "ProtArea"
  statements in Nef.Cfg and the <lev>[/<keys>] specification
  in a FileBone format file (if available).

- Requests for unlinked areas can be forwarded to the FileBone.

  The requests that have been forwarded to some uplink are
  stored in a file named after the configuration one, changing
  the extension to ".Fwd". Usually the configuration file is
  "Nef.Cfg", so the forwarded requests will be stored in
  "Nef.Fwd".

  The format is: <Tag> <Addr>, i.e. every line contains a Tag
  followed by the 4D Address of the downlink that made the
  request.

  When a new area is created, NEF looks into this file in order
  to find nodes to be added to the new "FileArea" definition.

  If a requested (and not yet defined) Tag is found in two or
  more FileBone files, the request is forwarded to the uplink
  defined in the first FileBone statement only.

  Don't mind if the Nef.Fwd file contains multiple entries for
  the same Tag. This can happen when multiple requests for the
  same area have been received. When the first file comes in
  and the area is created, all entries will be deleted while
  the link will be added once.


ΓòÉΓòÉΓòÉ 7.5.7.1. FileBone ΓòÉΓòÉΓòÉ


FileBone <file> [<fm> <to> <toadr> <acc> [<pre>]]

        Multiple FileBone statements are allowed.

        <file> is the filename of the FileBone-style file.

        If you want to enable the forward of requests for new
        areas from your downlinks to your uplink(s), you must
        specify the following fields (to be enclosed between
        quotes when containing space) so that they can be used
        to write netmail messages to your uplink's FileFix:

        <fm> is the "from" name.

        <to> is the "to" name.

        <toadr> is the "to" 4D address.

        <acc> is a <level>[/keys] specification, to limit the
              access of downlinks to request forwards addressed
              to <toadr> for the areas described in <file>.

        <pre> is an optional string to be prefixed to the area
              Tags that are being requested.

    Examples:

        FileBone \bbs\FileBone.Na "John Doe" SysOp 2:332/1 0

        The "\bbs\FileBone.Na" file is used by NEF, also for
        request forwards.

        When a downlink requests an area that is not currently
        defined in the NEF configuration (usually TicArea.Cfg)
        but is described in FileBone.Na, a netmail message is
        written by NEF from "John Doe" to "SysOp" of 2:332/1
        using the appropriate "from address" aka and "subject"
        (password) as per the "FileLink" definition of 2:332/1.
        The body contains a list of the requested area Tags, one
        per line.

        No (<acc> = "0") protection is specified (any downlink
        has access to request forwards).


        FileBone \bbs\FB.SP "John Doe" SysOp 2:332/1 30/a +

        Only downlinks with level equal or above 30 and with the
        'A' key have access to request forwards. The requested
        tags will be preceded by "+".

        If you need a space between the '+' and the tag, then you
        must specify a <pre> that contains a space, so you have
        to enclose it in quotes:

        FileBone \bbs\FB.SP "John Doe" SysOp 2:332/1 0 "+ "


ΓòÉΓòÉΓòÉ 7.5.7.1.1. FileBone Format ΓòÉΓòÉΓòÉ

                        FileBone Format

The format for the filebone style is:

  Area <Tag> <lev>[/<keys>] <flags> <desc>

  <Tag>   is the TIC area Tag.
          The original filebone format allows 8 character
          maximum but NEF is not that limited.

  <lev>   is the protection level of the area, for "FileFix"
          functions.
          The original format allows the range 0-4095 while NEF
          allows 0-65535.

  <keys>  are a set of protection keys (1..8, A..X).
          Not available in the original FileBone format.

  <flags> is a combinaton of !.*& and possibly other characters.

        By default (no flags) the area is uni-directional, from
        the uplink to the defined downlinks.

        ! : Can be found at any Filebone Hub.
        . : Only on some Filebone Hubs.
        * : Any node can hatch into.
        & : Do not send to downlinks.

   Others : Private distribution.

   Examples:

        ! : normal area from the uplink to its downlinks,
            available on all Filebone Hubs.

      !*& : return channel from the downlinks to the
            uplink, available on all Filebone Hubs.

       .* : bidirectional area (any node can hatch into),
            available on some Filebone hubs only.


  <desc> is the description for the area.


  Example:

  Area APBBS    0   P ApWorks OS/2 BBS programs
  Area NODEDIFF 0/f ! FidoNet: Weekly NodeList Updates


ΓòÉΓòÉΓòÉ 7.5.7.2. ForwardWildReq ΓòÉΓòÉΓòÉ


ForwardWildReq

        When a FileFix "Add" request contains wildcards, by
        default it is NOT forwarded to the filebone.
        This verb enables even this type of request forward.


ΓòÉΓòÉΓòÉ 7.6. Link Definitions ΓòÉΓòÉΓòÉ


                        Link Definitions


The FileLink statement is used to define a link, specifying its
password, attributes and privileges.

The FileArea statement is used to define a file area, specifying
its type and the list of connected systems (that must be defined
via FileLink statements).


ΓòÉΓòÉΓòÉ 7.6.1. FileLink ΓòÉΓòÉΓòÉ


FileLink <address> <password> [#<address>] <flags>
         [<attr> [<level>[/<keys>] [<WTAG> ...]]]

        The parameters of this keyword have been represented on
        two lines because of space, but they MUST be listed on a
        unique line in the .cfg file.

        This keyword defines a file link; you must use a
        FileLink statement for each of your links (both
        downlinks and uplinks).

        <address>  is the 4D address of the link.

        <password> is the case insensitive password to be used
                   for all TIC exchanges and for the Link Robot
                   function. NEF has no limit for the password
                   length, anyway you should be aware that other
                   similar programs might have limits, so check
                   with your downlink/uplink before choosing a
                   long password (8 characters should be OK for
                   everyone).

        #<address> This optional field indicates a "from" 4D
                   address to be used for the .TICs sent to this
                   link (overrides the zone-match and is in turn
                   overriden by the area override (see
                   "FileArea")).

        <flags>    This field is a (case insensitive) set of
                   characters:

                   <H|C|D|N|F>[<S|T>][<I|O|*>].

                   It can be 1 to 3 characters long:

                 - The first flag is mandatory; it defines the
                   flavour of the file-attaches that NEF will
                   create for .TIC and associated files.

                   Please note that this flag can be overridden
                   on a per-area basis by prefixing the link
                   address with a new flavour-flag in the
                   FileArea statement.

                   The available choices for this flag and the
                   consequent file-attach extension follow:

                   H -> .HLO (Hold)
                   C -> .CLO (Crash)
                   D -> .DLO (Direct)
                   F -> .FLO (Normal)
                   N -> .FLO (Normal)

                   The 'N' flag is provided for "compatibility",
                   but it's the same as 'F'.

                 - The second flag is optional: it defines
                   whether NEF must send a .TIC together with
                   the file or not.

                   S -> .TIC sent (default).
                   T -> .TIC not sent.

                   Usually the default is used (this flag can be
                   omitted), but sometimes points like not
                   receiving the .TIC file.

                   Please note that this flag can be overridden
                   on a per-area basis by prefixing the link
                   address with a new flag in the FileArea
                   statement.

                 - The third flag is optional. It is provided
                   for completeness and it is sometimes very
                   handy, but it is recommended not to use it
                   too often since its use might unnecessarily
                   complicate the interpretation of the
                   configuration.

                   It defines whether this link has
                   bidirectional access to file areas or not.

                   This is an override to the "area direction"
                   field of each FileArea definition.

                   Please note that this flag can be overridden
                   on a per-area basis by prefixing the link
                   address with a new flag in the FileArea
                   statement.

                   I -> Only Input is allowed from this link.
                        NEF will not send files.
                   O -> Only output is allowed to this link.
                        NEF will not accept files.
                   * -> Bidirectional link.

        <attr>     These are the (case insensitive) attributes
                   for the Link Robot's netmail replies:

                   K -> Kill/Sent
                   C -> Crash
                   H -> Hold
                   D -> Direct (equivalent to "CH")
                   N -> Normal (default)
                   O -> Normal (default)

                   The Private attribute is always implied.

                   ATTENTION: you should usually use the 'H'
                   attribute for file links that are not netmail
                   links too. Otherwise the "Normal" flavoured
                   netmail replies will be routed as per your
                   routing configuration instead of being holded
                   for the file link.

        <level>    This is an integer number in the range
                   0-65535 and represents the access level to
                   the Link Robot for this node. Defaults to 0.

                   If it is greater or equal to the protection
                   level of a certain file area, then this node
                   can link the area via the Link Robot,
                   provided it has the necessary keys.

        <keys>     is a subset of the following 32 element set:
                   {12345678ABCDEFGHIJKLMNOPQRSTUVWX}
                   and represents the (case insensitive) access
                   keys to the Link Robot for this node.

                   If <keys> contains all the keys that protect
                   a certain area, then the node can link the
                   area via the Link Robot, provided it has a
                   sufficient access level.

        <WTAG>     The optional list of <WTAG>s specifies the
                   area TAGs that must be automatically linked
                   to this node when they are automatically
                   created by NEF.

                   New areas can be automatically created when
                   unknown TAGs are found in ingoing .TICs (see
                   "NewAreasFrom" above in this reference).
                   You can make NEF automatically link the
                   downlink to the areas that match the <WTAG>
                   specification(s).


    Examples:


      - FileLink 2:332/593 pwd593 IN

        Node 2:332/593 has password "pwd503", is enabled to send
        .TICs to us ('I') and the file attaches addressed to it
        (if any) will be normal flavoured ('N').

        Note that file attaches to this node will only be
        possible if a local area override will be used, since
        the 'I' flag instructs NEF to accept files from the node
        but not to send to it.

        Nothing is specified about the Link Robot's reply flags
        and access level and keys, so this node will be able to
        link only areas with protection level 0 and no keys; the
        Robot's reply will be normal flavoured.

      - FileLink 2:331/196.1 pwd1961 H NK 300/ab

        Node 2:331/196.1 has password "pwd1961", nothing is
        specified about link direction (it will depend on the
        "area direction" and local overrides), the file attaches
        will be Hold flavoured ('H'), the reply netmails will be
        normal flavoured ('N') and kill/sent ('K'), the access
        level is 300 and the access keys are a,b.

      - FileLink 2:332/1 pwd1 #2:332/500 H N 900/ab MI* *OS2*

        Node 2:332/1 has password "pwd1", all the TICs sent to
        this node will use the from-address 2:332/500 (provided
        there is no aka override at the "FileArea" level), the
        file attaches will be Hold flavoured ('H'), the netmail
        replies will be normal flavoured ('N'), the access level
        is 900 and the access keys a,b.

        New areas whose TAG begins with "MI" or contains "OS2"
        will be automatically linked when they are automatically
        created by NEF.


ΓòÉΓòÉΓòÉ 7.6.2. FileArea ΓòÉΓòÉΓòÉ


FileArea <TAG> <path> I|O|* [#<address>] [-0] [[<flags>]<link> ...]

        This keyword defines an echo file area.

        If you have a small system, you can put the area
        definitions in the main configuration file (e.g.
        NEF.CFG). For systems with a large number of areas and
        links, it is recommended to use a separate file for the
        area definitions: see the "TicAreaCfg" keyword, formerly
        discussed in this documentation.

        ATTENTION: when using the "TicAreaCfg" separate file,
        you must put ALL the FileArea statements in that file.
        You are not allowed to put area definitions both in the
        main .cfg file and in the dedicated TicAreaCfg file at
        the same time !

        Please note that all the FileArea statements, if
        included in the main .cfg file, MUST be defined _after_
        the FileLink statements.

        <TAG> is the area TAG.

        <path> is the directory for the file area.

        I|O|*  is the (case insensitive) "area direction" and
               defines the default direction for the area:

            'I': we accept files from the listed nodes but do
                 not send to them, unless an override flag is
                 present before the <link> or in the pertinent
                 "FileLink" definition.

                 This should usually be used for "pre" areas, in
                 which files must be collected from downlinks
                 and sent to the area coordinator via the
                 uplink, which will probably need a local 'O'
                 override.

            'O': we send files to the listed nodes but do not
                 accept from them, unless an override flag is
                 present before the <link> or in the pertinent
                 "FileLink" definition.

                 This should usually be used for areas that must
                 be distributed to downlinks. The uplink will
                 need a local 'I' override before its <link>
                 field or a global one in its FileLink
                 definition.

            '*': the area is bidirectional, so we both send and
                 accept files to/from the listed nodes, unless
                 an override flag is present before the <link>
                 or in the pertinent "FileLink" definition.

                 This should be used for bidirectional areas, in
                 which everybody is allowed to "hatch" files.

        #<address>: defines the primary address to be used for
                 this area; overrides both the default
                 zone-match and the aka overrides in "FileLink"
                 definitions

             -0: When the "-0" (zero) is specified, the area is
                 "Passthru", that is its files will be deleted
                 when already sent to all the downlinks. Please
                 note that ANY file (apart from FILES.*) present
                 in the <path> and not attached to any system
                 will be deleted.

                 NEF must be explicitly instructed to delete the
                 old files in passthru areas, usually in some
                 maintenance event.

                 See also the "-p" and "CLEAN" command line
                 options.

        The list of linked nodes follows; each node can have
        some <flags> attached before the node address. The
        available flags are the same as for the <flags> field in
        the "FileLink" statement.

        <flags>    This is an optional (case insensitive) field
                   made up of 1 to 3 characters:
                   [H|C|D|N|F][S|T][I|O|*].

                 - The first flag defines the flavour of the
                   file-attaches that NEF will create for .TIC
                   and associated files.

                   Please note that this flag overrides that in
                   the pertinent "FileLink" statement.

                   The available choices for this flag and the
                   consequent file-attach extension follow:

                   H -> .HLO (Hold)
                   C -> .CLO (Crash)
                   D -> .DLO (Direct)
                   F -> .FLO (Normal)
                   N -> .FLO (Normal)

                   The 'N' flag is provided for "compatibility",
                   but it's the same as 'F'.

                 - The second flag defines whether NEF must send
                   a .TIC together with the file or not.

                   S -> .TIC sent.
                   T -> .TIC not sent.

                   Please note that this flag overrides that in
                   the pertinent "FileLink" statement.

                 - The third flag defines the direction of the
                   link.

                   Please note that this flag overrides that in
                   the pertinent "FileLink" statement, which in
                   turn overrides the "area direction".

                   I -> Only Input is allowed from this link.
                        NEF will not send files.
                   O -> Only output is allowed to this link.
                        NEF will not accept files.
                   * -> Bidirectional link.

        <link>     This is a 4D address, that can be abbreviated
                   whenever the preceding address has the same
                   zone, zone:net or zone:net/node.

                   For the first <link>, if incomplete, the
                   primary address for the area is used; anyway
                   NEF always writes the first address in
                   complete form when rewriting the area due to
                   a Link Robot command.

    Examples:

    Please note that the situation might be a little different
    from what explained below, since the FileLink definitions
    could have some overriding flags.


    FileArea AREA1 d:\file\area1 O I2:332/1 504.1 .2 1:2/3

    Typical area definition, where we receive from the
    uplink (marked with 'I') and forward to the listed downlinks
    (area direction 'O').


    FileArea AREA2 d:\file\area2 O -0 I2:332/1 504.1 .2 1:2/3

    Same as above, but passthru.


    FileArea AREA3 d:\file\area3 I O2:5/1 3/1 332/504.2 .3

    This is a "reverse" area, where we receive from the listed
    nodes (area direction 'I') and send to the one marked with
    'O'.


    FileArea AREA4 d:\file\area4 * 2:5/1 3/1 332/504.2 .3

    This is a bidirectional area (direction '*'), where we
    receive from any of the listed nodes and forward to all the
    others.


    FileArea AREA5 d:\file\area5 O #2:332/500 I2:332/596 C555

    A normal "up-link to down-links" area ('O'); we use
    2:332/500 as the primary address, accept files from
    2:332/596 and forward to 2:332/555 with a crash flavoured
    file attach.


    FileArea AREA6 d:\file\area6 O S2:332/504.1 10:10/0 *100/1

    Normal "up-link to down-links" area ('O'); 10:100/1 is the
    only node enabled to send to us (bidirectional override
    '*'); we forward to 2:332/504.1 and 10:10/0. If we hatch
    files, we send to 10:100/1 too, since it is bidirectional.
    We send the .TIC accompanying files to 2:332/504.1 ('S')
    even if it had a 'T' flag in its FileLink definition.



ΓòÉΓòÉΓòÉ 7.7. Compress Definition File ΓòÉΓòÉΓòÉ


                    COMPRESS DEFINITION FILE


The file specified in the CompressCfg statement is a sequence of
Archive definition blocks, each one starting with "Archiver" and
ending with "End Archiver". You can find an example in the
Compress.Cfg file included in the NEF distribution pack.

The order of the archive definition blocks within this file may
be important: when trying to unpack a compressed file, the list
of archivers is scanned in a reverse order.

In the case of two archivers that use the same identification
string (e.g. ARC and PAK), you must specify the archiver that
can unpack both (PAK) after the other one (ARC).

The compress.cfg file can be shared between DOS and OS/2
applications: the "DOS" and "OS2" keywords are available to
distinguish between the commands to be used under DOS and OS/2.
O.S. specific archivers or commands must be prefixed with the
relevant keyword.

IMPORTANT NOTE: The lines that begin with "DOS" or "OS2" are
parsed by the corresponding version of NEF. If you need the OS/2
version to execute a DOS command, you MUST NOT use the DOS
keyword: if you do, it will never parse that line; if you do
not, ir will execute the DOS command "normally", provided you
have installed OS/2's Dos support.

See the examples below.


ΓòÉΓòÉΓòÉ 7.7.1. Archiver ΓòÉΓòÉΓòÉ


Archiver <ARCname>

        Starts the Archive definition block.

        <ARCname> is the name used to identify this archiver.

    Example:

        Archiver ZIP


ΓòÉΓòÉΓòÉ 7.7.2. Extension ΓòÉΓòÉΓòÉ


Extension  <ext>

        Specifies the default extension for the compressed
        files.

    Example:

        Extension ZIP


ΓòÉΓòÉΓòÉ 7.7.3. Ident ΓòÉΓòÉΓòÉ


Ident <ofs>,<ID>

        <ofs> is a decimal integer number representing the
        offset at which an archive identity marker <ID> must be
        present.

        Negative values can be used to indicate offsets from the
        END of a compressed file. -1 means "the last byte", -2
        "the second last byte" and so on.

        <ID> is a series of hexadecimal figures which represent
        the bytes of the marker string that must be present at
        the specified offset of the archive file.

    Example:

        Ident 0,504b0304  ; "PK^c^d"


ΓòÉΓòÉΓòÉ 7.7.4. Add ΓòÉΓòÉΓòÉ


Add <command>

        Specifies the command to add files to an archive.
        %a and %f are translated to the name of the archive and
        file to add.

    Example:

        Add zip -jk %a %f


ΓòÉΓòÉΓòÉ 7.7.5. Extract ΓòÉΓòÉΓòÉ


Extract <command>

        Specifies the command to extract files from an archive.
        %a and %f are translated to the name of the archive and
        file to extract.

    Example:

        Extract unzip -qqnjC %a %f


ΓòÉΓòÉΓòÉ 7.7.6. View ΓòÉΓòÉΓòÉ


View <command>

        This line is recognized and accepted for compatibility,
        but not used.


ΓòÉΓòÉΓòÉ 7.7.7. End Archiver ΓòÉΓòÉΓòÉ


End Archiver

        This statement is used to close a Archive definition.


ΓòÉΓòÉΓòÉ 7.7.8. Examples ΓòÉΓòÉΓòÉ

                            Examples


    Complete example 1 (you need OS/2 only):

Archiver ZIP
     Extension     ZIP
     Ident         0,504b0304
     Add           zip -jk %a %f
     Extract       unzip -qqnjC %a %f
     View          unzip -v %a
End Archiver


    Complete example 2 (you need DOS only):

Archiver ZIP
     Extension     ZIP
     Ident         0,504b0304
     Add           pkzip -a %a %f
     Extract       pkunzip -n %a %f
     View          pkzip -v %a
End Archiver


    Complete example 3 (you need both OS/2 and DOS):

Archiver ZIP
     Extension     ZIP
     Ident         0,504b0304
OS2  Add           zip -jk %a %f
DOS  Add           pkzip -a %a %f
OS2  Extract       unzip -qqnjC %a %f
DOS  Extract       pkunzip -n %a %f
OS2  View          unzip -v %a
DOS  View          pkzip -v %a
End Archiver


    Complete example 4 (archiver to be used under DOS only):

DOS Archiver ZOO
DOS     Extension       ZOO
DOS     Ident           0,5a4f4f                        ; "ZOO"
DOS     Add             zoo a: %a %f
DOS     Extract         zoo e:O %a %f
DOS     View            zoo v %a
DOS End Archiver


    Complete example 5 (it's a DOS executable, to be used under
                        DOS or OS/2 indifferently):

Archiver ZOO
     Extension       ZOO
     Ident           0,5a4f4f                        ; "ZOO"
     Add             zoo a: %a %f
     Extract         zoo e:O %a %f
     View            zoo v %a
End Archiver


ΓòÉΓòÉΓòÉ 8. SHAREWARE ΓòÉΓòÉΓòÉ


                       S H A R E W A R E


If you like this program and continue using it, you should pay
the author for his work, as per the ShareWare concept of
distribution.

Please see LICENSE.DOC and REGISTER.DOC for information.

Thank you for your interest in ApWorks programs.


ΓòÉΓòÉΓòÉ 8.1. License.Doc ΓòÉΓòÉΓòÉ


                          ΓòöΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòù
                          Γòæ       Γòæ
                          Γòæ N E F Γòæ
                          Γòæ       Γòæ
                          ΓòÜΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓò¥

                        L I C E N S E

                         P O L I C Y

                         March  1996


The NEF software (program and accompanying documentation) are:

Copyright (c) 1991-1996 Alberto Pasquale, all rights reserved.


                      DISTRIBUTION FORMAT


This software is distributed in a locked RAR archive, with
embedded authenticity-verification information.

The distribution of modified archives, including those derived
from the conversion to a different archiver, is explicitly
prohibited.


                      S H A R E W A R E


This software is distributed as ShareWare: you are granted the
right to evaluate the program for a maximum of 30 days before
paying the author. After the evaluation period, you are required
to either register (see REGISTER.DOC) or stop using the program.

You are encouraged to distribute the original and unmodified
package freely, in any form and on any media, provided you do
not charge any fee for the program itself.

This package could be included in CD-ROM collections,
subscription download areas, BBS packages, provided it remains
in its complete and unmodified original archive.

In any case, the user must register with the author after the
evaluation period.

IMPORTANT: the registration is NOT a trade transaction, it is to
be considered as payment of royalties; therefor the registration
key is personal and NOT transferrable.


                         DISCLAIMER


This software is provided on an "as is" basis without warranty
of any kind, expressed or implied, including but not limited to
the implied warranties of merchantability and fitness for a
particular purpose.

The person using the software bears all risk as to its quality
and performance.

The author will not be liable for any special, incidental,
consequential, indirect or similar damages due to loss of data
or any other reason.


ΓòÉΓòÉΓòÉ 8.2. Register.Doc ΓòÉΓòÉΓòÉ



                   **   ** ******* *******
                   ***  **  **   *  **   *
                   **** **  ** *    ** *
                   ** ****  ****    ****
                   **  ***  ** *    ** *
                   **   **  **   *  **
                   **   ** ******* ****


       (C) Copyright 1991-1996  by  Alberto Pasquale

           A L L   R I G H T S   R E S E R V E D


For licensing terms and disclaimer, see LICENSE.DOC.

This program required a lot of work: by registering you will
support me in developing this and other similar products.

You will receive a registration Key that removes the initial 2
second pause and makes the program show "Registered <month/year>
To: <Reg.String>" instead of the registration request banner.

The registration is guaranteed valid for all future minor
updates and, in any case, for all versions that will be released
in a period of 2 years after registration. After this period, an
upgrade fee might possibly be required in the case of major new
releases.


ΓòöΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòù
Γòæ                                                             Γòæ
Γòæ Registration fee: US$ 20, DEM 30, ITL 30,000 or (see below) Γòæ
Γòæ                                                             Γòæ
ΓòÜΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓò¥



ΓòÉΓòÉΓòÉ 8.2.1. How to Register ΓòÉΓòÉΓòÉ


                        HOW TO REGISTER



Registering is quite easy; you can register:


- Directly with me by cash, check or international postal money
  order.

- via local Registration Site in Germany, Denmark (Sweden,
  Norway), UK.

- via BMT Micro (Wilmington, NC, USA), by credit card, money
  order, cashiers check, personal check, German or British
  currency.

- via PsL (Houston, TX, USA), by credit card.


The registration key will be sent you via internet e-mail or
crash netmail depending on availability; fax and postal mail
will be used only in case of problems.

Should you not receive your registration key in a reasonable
time, please feel free to contact me.

Please allow at least 3 weeks for response to international
airmail.


Please address your requests, complaints, suggestions to:

  Alberto Pasquale of 2:332/504@fidonet

  [e-mail]

  2:332/504@fidonet [phone] ISDNC V34+ V32T H16
  2:332/524@fidonet [phone] ISDNC V34  V32T H16 FAX


ΓòÉΓòÉΓòÉ 8.2.1.1. Author's ΓòÉΓòÉΓòÉ

            Hot to register directly with the author

You have to send the registration information and money to:

      Alberto Pasquale
      Viale Verdi 106
      41100 Modena
      Italy


ΓòÉΓòÉΓòÉ 8.2.1.1.1. Cash ΓòÉΓòÉΓòÉ


Cash:
      Just put the (accurately hidden) banknotes (US$ 20, DEM
      30, ITL 30,000) together with Register.For in an envelope.
      If you do not have US dollars, German marks or Italian
      liras and do not like going to the bank, you can send the
      equivalent in your currency, provided it is commonly
      exchangeable. Please be aware that coins are nice gifts
      but are NOT exchangeable.


ΓòÉΓòÉΓòÉ 8.2.1.1.2. Check ΓòÉΓòÉΓòÉ


Check:
      Just put the check (accurately hidden) together with
      Register.For in an envelope. Please read carefully the
      following instructions:

      - Eurocheque: ITL 30,000 (thirty thousand).

      - Italian check: 30.000 lire

      - Other (bank) checks: US$ 25, DEM 35, ITL 40,000 or
        equivalent (the surcharge is to partially cover the
        foreign check redemption cost).

      ATTENTION: NO Postal Checks please.


ΓòÉΓòÉΓòÉ 8.2.1.1.3. Postal Money Order ΓòÉΓòÉΓòÉ


Postal Money Order:

      Just go to the post office and ask for an _INTERNATIONAL_
      postal money order. It is best to go to a major post
      office, since minor ones are generally not used dealing
      with international money orders. Usually you can choose
      whether to use your currency or the recipient's.

      Please be sure to specify the necessary registration
      information in the "sender message" field or send
      Register.For separately to the author.

      - International money order in italian liras: ITL 30,000
        (thirty thousand).

      - International money order in your currency: US$ 23,
        DEM 35 or equivalent.

      - Italian money order "vaglia": 30.000 lire.

      IMPORTANT: Please DO NOT send me normal "domestic" postal
      money orders, since they are not payable outside of your
      country; you must use INTERNATIONAL postal money orders.

      If you would like to receive the key soon, you
      can FAX me ([phone]) the receipt of the
      postal money order together with REGISTER.FOR.


ΓòÉΓòÉΓòÉ 8.2.1.2. Local Registration/Support sites ΓòÉΓòÉΓòÉ


Local Registration/Support Sites:

       If you choose this way, you will have contacts with the
       local supporter only: you will send him the money and he
       will send you back the key in a few days.


ΓòÉΓòÉΓòÉ 8.2.1.2.1. Germany ΓòÉΓòÉΓòÉ


Germany:

       Roland Schiradin
       Stockbornstr. 10
       65343 Eltville
       Germany

       Fidonet:  2:2454/169 Mail Only
       Internet: [e-mail]

       He has the APWORKS support echo and TIC file-areas for
       my programs available. Besides he can provide you with
       information about the nodes carrying APWORKS in
       Germany.

       He has the latest version of ApWorks programs available
       for F/R with the same magics listed in Readme.1st.

       To register, please contact him before sending money.
       Anyway the fee should be between DEM 25 and DEM 30,
       depending on the current exchange rate.


ΓòÉΓòÉΓòÉ 8.2.1.2.2. Denmark/Sweden/Norway ΓòÉΓòÉΓòÉ


Denmark
Sweden
Norway:
       Jens Holm
       Skanderupgade 9, D2
       8660 Skanderborg
       Denmark

       Reg. Fee: 125.- DKR.

       Can be paid cash, check or postal order.

       Email:
       2:238/888.0@fidonet, 9:451/180@virnet, 81:445/40@os2net

       for swedish and norwegian users, if in doubt, please
       contact regsite for payment in local currency, reply will
       be crashed back.


ΓòÉΓòÉΓòÉ 8.2.1.2.3. United Kingdom ΓòÉΓòÉΓòÉ


United Kingdom:

        Vince Coen
        Applewood House
        Epping Road
        Roydon, Harlow
        Essex, CM19 5DA, UK

        Fidonet: 2:257/609

        Reg. Fee: GBP 15.00

        Payment can be in Cash, Cheque (bankers card number on
        order form please) or EuroCheck.

        Or direct to my bankers. Payment MUST be in Pounds Sterling.

        For payment though the bank:
        Bank:         First Direct.
        Sort code:    40-47-86.
        Account:      00449334
        Account name: Vincent Coen.

        Payment reference must include Sysop name and node number.


ΓòÉΓòÉΓòÉ 8.2.1.3. BMT Micro ΓòÉΓòÉΓòÉ

                 How to register with BMT Micro


You have to fill in the BmtMicro.For registration form and send
it (or equivalent information) to BMT Micro.

ATTENTION: for any question regarding the program, its
registration, support etc, you must contact me directly.
Please contact BMT Micro to order ONLY.

Usually your key will be delivered within 2 business days.

In certain holiday periods (Christmas, Easter, end of July,
first half of August) there might be some delay (a few days for
Christmas or Easter, a couple of weeks in July/August). If you
think your order is particularly late, please contact me first !


       Mail Orders To: BMT Micro
                       PO Box 15016
                       Wilmington, NC  28408
                       U.S.A.

         Voice Orders: 8:00am - 7:00pm EST (-5 GMT)
                       [phone] (Orders only)
                       [phone] (Orders / Order Inquires)

           Fax Orders: [phone] 24 hours, 7 days a week
                       [phone] 24 hours, 7 days a week

Online Orders via BBS: [phone] 10 lines, all 14.4K
                       [phone] 28.8k v.FC

       BBS via Telnet: bmt.wilmington.net

       via Compuserve: Thomas Bradford, 74031,307
         via Internet: [e-mail]


Credit cards: Visa, Mastercard, Discover, American Express,
              Diner's Club.

They also accept money orders, cashiers checks, personal checks,
German or British currency via registered mail.

Personal checks are subject to clearance.


ΓòÉΓòÉΓòÉ 8.2.1.4. PsL ΓòÉΓòÉΓòÉ

           How to register with PsL (by credit card)


You must fill in the PsL.Crd and Register.For forms; then
you must send BOTH of them to PSL directly (they will forward
Register.for information to me).

You can order with MasterCard, Visa, American Express or
Discover Card: the charge is US$ 25.

ATTENTION: you MUST NOT send me any information about your
credit card. If you do, I am NOT allowed to forward your credit
card info to PSL.

ATTENTION: for any question regarding the program, its
registration, key delivery etc, you must contact me directly.
You must contact PSL to order ONLY.

PSL will notify me your order within one business day and I will
usually send your key by e-mail or crash netmail within 24h, so
if you order by fax or phone, you should usually receive your
key within 2 business days.

ATTENTION: In certain "holiday" periods (Christmas, Easter, end
of July, first half of August) there might be some delay (a few
days for Christmas or Easter, a couple of weeks in July/August).
If you think your order is particularly late, please contact me
first !

ATTENTION: It may happen that the PSL operator asks you for your
preferred diskette format. You must be aware that this may be
"standard" PSL procedure, but I will send you a key ONLY (via
e-mail, crash netmail, fax or letter), since you already have
the program.

IMPORTANT: Please, be sure to always give PsL the address where
you want to receive your key: e-mail address, fidonet name _and_
address, fax number, and/or complete postal address. If you are
not in the fidonet nodelist and I don't receive enough
information, I will be forced to send you an air-mail letter
(2-3 weeks for delivery). In the case of doubts, you can send
the Register.For to me too, by e-mail, crash netmail or fax.

Credit card registrations may be made by the following methods
(please be sure to always include all the necessary information
from BOTH Register.For and PsL.Crd).

      -- Phone PsL at:

         800-2424-PsL i.e. 800-2424-775 (Toll free from USA)

         [phone] (international)

         PSL Office Hours:

         7:00 a.m. to  6:00 p.m. CST Monday->Thursday
         7:00 a.m. to 12:30 p.m. CST Friday

         Be sure to have BOTH Register.For AND PsL.Crd
         available to give order information to PSL.
         First of all, mention the PSL part number specified
         in PsL.Crd.

      -- FAX PsL at [phone]

      -- Email PsL at CompuServe userid 71355,470

      -- Write PsL at:
         The Public (software) Library
         P.O. Box 35705
         Houston, TX 77235-5705, USA

      Please, let me insist one more time:

      ΓòöΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòù
      Γòæ The above numbers are for ORDERS ONLY.                Γòæ
      Γòæ Any question about the status of the shipment of the  Γòæ
      Γòæ order (registration key), registration options,       Γòæ
      Γòæ product details, technical support, etc, must be      Γòæ
      Γòæ directed to the author, at the address given above in Γòæ
      Γòæ this documentation.                                   Γòæ
      ΓòÜΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓò¥


ΓòÉΓòÉΓòÉ 8.2.2. How to fill in Register.For ΓòÉΓòÉΓòÉ


            INSTRUCTIONS FOR COMPILING REGISTER.FOR


To avoid errors in the key, please PRINT.

Thank you very much for your support !


ΓòÉΓòÉΓòÉ 8.2.2.1. Name ΓòÉΓòÉΓòÉ


Name:
     Your complete name.

     Example: John Doe


ΓòÉΓòÉΓòÉ 8.2.2.2. Reg ΓòÉΓòÉΓòÉ


Reg:
     The registration string you want displayed by the program.
     You can use any character in the IBM set (including special
     national characters above ASCII 127; if you do not use code
     page 437 (USA), please specify the code numbers) and you can
     use lowercase and uppercase at your preference.
     Maximum length: 63 characters.

     Usually it should be the same as your name, in which case
     you can omit this field.


ΓòÉΓòÉΓòÉ 8.2.2.3. e-mail to ΓòÉΓòÉΓòÉ


e-mail to:
     This is your internet e-mail address, if available.


ΓòÉΓòÉΓòÉ 8.2.2.4. Netmail to ΓòÉΓòÉΓòÉ


Netmail to:
     You have to specify the complete destination field for the
     netmail message.

     Examples: John Doe of 1:200/300.4
               John Doe of 1:200/300.0


ΓòÉΓòÉΓòÉ 8.2.2.5. Crash to ΓòÉΓòÉΓòÉ


Crash to:
     You have to specify the data necessary for crashing the
     message. Usually this should be your system or your Boss
     (if you are a point).

     I will call as 2:332/504@fidonet.

     - If your system (or your Boss) is 24h and it is in the
       fidonet nodelist, you can omit this field.

     - If your system is not 24h, please give me a 24h system to
       which I can crash your netmail for routing.

     - If the system in consideration is not in the fidonet
       nodelist, please add its complete phone number and modem
       type.

     Examples: 1:200/400@fidonet
               9:800/700@ABCnet [phone] V34, ISDNC


ΓòÉΓòÉΓòÉ 8.2.2.6. Fax ΓòÉΓòÉΓòÉ


Fax:
     This is your (24h) fax number, if any.


ΓòÉΓòÉΓòÉ 8.2.2.7. Address ΓòÉΓòÉΓòÉ


Address:
     The postal address is the last opportunity of sending you
     the key.


ΓòÉΓòÉΓòÉ 8.2.2.8. Version ΓòÉΓòÉΓòÉ


Version:
     You should indicate BOTH the version number AND the
     Operating System.

     Example: ver. 2.34  OS/2

     This is not essential and is included for statistical
     purposes only (the key works with all current versions).


ΓòÉΓòÉΓòÉ 8.2.2.9. Notes ΓòÉΓòÉΓòÉ


Notes:
     You can send me your wish list for future versions,
     or anything you like.


ΓòÉΓòÉΓòÉ 8.2.3. How to fill in BmtMicro.For ΓòÉΓòÉΓòÉ


            INSTRUCTIONS FOR COMPILING BMTMICRO.FOR


The first section contains data necessary for BMT Micro (your
name, company, address, phone and fax).

The second section contains the "Registration Information" that
will be relayed to me so that I can build the key and deliver it
to you.

The third section contains the product and cost indication
(US$25 plus 6% sales tax for NC residents). The registration is
valid for OS/2 or Dos indifferently.

The forth section contains data for Credit Card payment.

To avoid errors, please PRINT.

Thank you very much for your support !


ΓòÉΓòÉΓòÉ 8.2.3.1. Reg ΓòÉΓòÉΓòÉ


Reg:
     The registration string you want displayed by the program,
     ASCII characters only (<127).
     Maximum length: 63 characters.


ΓòÉΓòÉΓòÉ 8.2.3.2. e-mail to ΓòÉΓòÉΓòÉ


e-mail to:
     This is your internet e-mail address, if available.


ΓòÉΓòÉΓòÉ 8.2.3.3. Netmail to ΓòÉΓòÉΓòÉ


Netmail to:
     You have to specify the complete destination field for the
     netmail message.

     Examples: John Doe of 1:200/300.4
               John Doe of 1:200/300.0


ΓòÉΓòÉΓòÉ 8.2.3.4. Crash to ΓòÉΓòÉΓòÉ


Crash to:
     You have to specify the data necessary for crashing the
     message. Usually this should be your system or your Boss
     (if you are a point).

     I will call as 2:332/504@fidonet.

     - If your system (or your Boss) is 24h and it is in the
       fidonet nodelist, you can omit this field.

     - If your system is not 24h, please give me a 24h system to
       which I can crash your netmail for routing.

     - If the system in consideration is not in the fidonet
       nodelist, please add its complete phone number and modem
       type.

     Examples: 1:200/400@fidonet
               9:800/700@ABCnet [phone] V34, ISDNC


ΓòÉΓòÉΓòÉ 8.3. Register.For ΓòÉΓòÉΓòÉ




                     NEF Registration Form

                        (Please PRINT)

See Register.Doc for instructions:               Date: __/__/__

Name: _________________________________________________________

Reg.: _________________________________________________________

e-mail to: ____________________________________________________

Netmail to: ___________________________________________________

Crash to: _____________________________________________________

Fax: __________________________________________________________

Address: ______________________________________________________

         ______________________________________________________

         ______________________________________________________

Version: _.___     OS/2 ( )    DOS ( )

Notes: ________________________________________________________

_______________________________________________________________

_______________________________________________________________




ΓòÉΓòÉΓòÉ 8.4. BmtMicro.For ΓòÉΓòÉΓòÉ

-------------------------------------------------------------------------------

                                   BMT Micro
                             NEF Registration Form

                   *****************************************
                   * DO NOT SEND this form to the author ! *
                   *****************************************

      See Register.Doc for instructions, please PRINT:    Date: __/__/__

      Name: ____________________________________________________________

      Company: _________________________________________________________

      Address: _________________________________________________________

      __________________________________________________________________

      City: _______________________   State/Province: __________________

      Country: ____________________________ Postal Code: _______________

      Phone: ___________________________________________________________

      Fax: _____________________________________________________________


                            REGISTRATION INFORMATION

      Reg.: ____________________________________________________________

      e-mail to: _______________________________________________________

      Netmail to: ______________________________________________________

      Crash to: ________________________________________________________


      Product: NEF (by Alberto Pasquale)               Price:  US$ 25.00

      North Carolina residents, please add 6% sales tax:      +US$  1.50

                                                       Total:  US$ __.__

      For credit card payment only:

      Circle one: VISA / Master / Discover / AMEX / Diner's Club

      Credit card number     : _________________________________________

      Expiration date        : ___/___

      Authorization signature: _________________________________________

-------------------------------------------------------------------------------


ΓòÉΓòÉΓòÉ 8.5. PsL.Crd ΓòÉΓòÉΓòÉ

-------------------------------------------------------------------------------




                      NEF Credit Card Registration Form
                      PSL Part number 11474

                  *****************************************
                  * DO NOT SEND this form to the author ! *
                  *****************************************

        Please read carefully Register.Doc for instructions.


                                          Date _________________________


  Cardholder's name, exactly as it appears on the credit card:

             ___________________________________________________________

  [Company:] ___________________________________________________________


  Billing address for the card:

             ___________________________________________________________

             ___________________________________________________________

             ___________________________________________________________

    Payment by:   ( ) MasterCard          ( ) Visa
                  ( ) American Express    ( ) Discover Card

    Card #:  ________________________________  Exp. Date:  _____________

    Signature of cardholder: ___________________________________________




-------------------------------------------------------------------------------


ΓòÉΓòÉΓòÉ 9. Sample config files ΓòÉΓòÉΓòÉ

                Some example configuration files


ΓòÉΓòÉΓòÉ 9.1. Point or minimal Configuration ΓòÉΓòÉΓòÉ


;         NEF 2.33, (c) Copyright 1991-1996 Alberto Pasquale

;                          Nef.Cfg Example

;                        Minimal configuration


; RegKey <RegKey>                     ; registration Key
Address      2:332/504.1              ; Address
StatusLog    d:\point\log\nef.LOG     ; Binkley Style Log File
NetFile      d:\point\inb             ; Inbound
OutBound     d:\point\outbound        ; Primary Outbound
TicHold      d:\point\tichold         ; To hold outgoing .TICs
CheckCRC                              ; Check ingoing files

FileLink 2:332/504 Password C         ; Attach with Crash flavour

FileArea APBBS    d:\point\file\apbbs    O 2:332/504 ; Output only
FileArea AREA1    d:\point\file\area1    * 2:332/504 ; This is bidirectional


ΓòÉΓòÉΓòÉ 9.2. Full configuration ΓòÉΓòÉΓòÉ


;          NEF 2.33, (c) Copyright 1991-1996 Alberto Pasquale

;                           Nef.Cfg  Example

;                          Full configuration



;                               SYSTEM


; RegKey XXXXXXXXXXXXXXXXXXXXXXXXXXXXX  ; for Registered users

  Address      2:332/504.0              ; Primary Address
  Address      2:332/524.0              ; Second line
  Address      2:332/500.0              ; Hub
  Address      81:449/9108.4            ; Point in OS2Net

  StatusLog    d:\bbs\log\nef.log       ; Binkley Style Log File
; EchoTossLog  d:\bbs\squish\echotoss.log

  NetFile      d:\bbs\inb\net           ; Inbounds
  NetFile      d:\bbs\inb\netp

  OutBound     d:\bbs\out\fido          ; Primary Outbound
  OutBound     d:\bbs\out\amiga 39      ; Outbound for zone 39

  TicHold      d:\bbs\tichold           ; To hold outgoing .TICs

  BusyFlags                             ; .BSY support (multitasking)

; NoRaidBeforeHatch                     ; Skip TicFix when hatching

  MsgSize 32000                         ; Max size before msg split

  TicAreaCfg   d:\bbs\nef\TicArea.Cfg   ; Where file areas are defined

  CompressCfg  d:\bbs\squish\compress.cfg ; OS/2 Only

  SquishCfg    d:\bbs\squish\squish.cfg   ; Optional support for Squish
  MaxPrm       d:\bbs\max\max.prm         ; Optional support for Max 3.x
; MaxAreaAdd   d:\bbs\max\filearea.ctl 0 Transient Tic.New
; MaxAreaCompile siltp max -a -2a
  FileBaseUpdate                        ; Internal Max filebase update
; UniqueDmpLine

;                            TIC PROCESSING


; NoSecure                      ; Disable security checks
; NoReplace 3* AP*              ; Disable replace in spec. areas

  CheckCRC                      ; Check CRC of ingoing files
  Touch                         ; Touch ingoing files

; MultiLineDesc 31              ; Enable Files.bbs multi-line descriptions

  NewAreasPath c:\file                  ; Path for auto-created areas
  NewAreasFrom 10:10/100                ; Address authorized for auto-creation
  NewAreasFrom 2:339/900 #2:332/500     ; Address override for created areas

  DescStart "/bt [00] " 1* 2*           ; Description prefix in areas 1*, 2*
  DescStart "/b [00] " 3*               ; A different one for areas 3*

  TagFwd 1-Comm Bbs AC*n TRY.*          ; Some area split forward
  TagFwd GenNode Pointlst PTLIST.*

; FeatureLoad d:\bbs\nef\MyDll          ; Feature DLL support
; Feature CfgItem1 "This is Item 1"
; Feature CfgItem2 "This is Item 2"



;                            TIC ANNOUNCEMENTS

; Default announcement parameters

  FromNode     2:332/504.0              ; For the message header
  ToNode       2:332/504.0
  From         Alberto Pasquale
  To           All
  Subj         New Echo Files
  Attr                                  ; no special attribute

  Prefix       d:\bbs\nef\PREFIX.NEF    ; Message body prefix, suffix, origin
  Suffix       d:\bbs\nef\SUFFIX.NEF
  Origin       <ApWorks Modena I [phone]/3>

; Announcement areas: default parameters can be overridden

  AreaTag      APWORKS                  ; If SquishCfg can't be used,
  Announce     APBBS*                   ; path and type of area
  Prefix       RelPre.NEF               ; must be specified.
  Subj         New ApWorks files

  AreaTag      OS2BBS
  Announce     APBBS*
  NoAnnounce   *DOS*                    ; Do not announce Tags
  Prefix       RelPre.NEF               ; that contain "DOS".
  Subj         New APBBS files

  AreaTag      SWN_332.500
  Announce     FLEET*
  Subj         New FleetStreet files

  AreaTag      SWN_332.500
  Announce     HARALD* OS2POINT CFOS
  Subj         New files from Harald Kamm

  AreaTag      NETMAIL
  Announce     <OUTVIEW> <DEF>
  From         NEF
  To           Alberto Pasquale
  Subj         Not Announced Elsewhere
  HighAsciiOk

  AreaTag      NETMAIL
  Announce     <BAD>
  From         NEF
  To           Alberto Pasquale
  Subj         Processed with Errors


;                               LINK ROBOT


  AutoLink NEF                  ; The Link Robot will answer to these names
  AutoLink Raid
  AutoLink TicFix

  NetMail d:\bbs\mail\net -$
  NetMail d:\bbs\mail\os2net -$ -p81:449/9108.4

; KillReceived                     ; Kill instead of marking as received
  AreaDescWrap 25 79               ; Word wrap for area description
  HelpFile d:\bbs\nef\NefHelp.Txt  ; Returned when help requested

  ProtArea 1*      300/A        ; Areas 1* and 2* are protected
  ProtArea 2*      300/B
  ProtArea *         0          ; All the others are free

  FileBone d:\bbs\misc\FileAp.Lst
  FileBone d:\bbs\misc\FileBone.Na "Alberto Pasquale" SysOp 2:332/1 0

; ForwardWildReq                ; Forward requests with wildcards.

  FileLink 2:332/593 pwd593 IN           ; Simplest link definition
  FileLink 2:331/196 pwd196 H NK 300/a   ; This has a Link Robot access
  FileLink 2:332/123 pwd123 #2:332/500 H N 300/ab MI* FW* ; Full definition

; If TicAreaCfg is not used, you can put area definitions here:

; FileArea AREA1 d:\file\area1 O I2:332/1 504.1 .2 1:2/3
; FileArea AREA2 d:\file\area2 O -0 I2:332/1 504.1 .2 1:2/3


ΓòÉΓòÉΓòÉ 9.3. Sample Prefix ΓòÉΓòÉΓòÉ


Echo Files received for distribution:

===============================================================================


ΓòÉΓòÉΓòÉ 9.4. Sample Suffix ΓòÉΓòÉΓòÉ

===============================================================================

F/R allowed to everybody (06:00->23:00 GMT)
2:332/504@fidonet [phone] (ISDNC/V34+/VFC/V32T/H16)
2:332/524@fidonet [phone] (ISDNC/V34/VFC/V32T/H16)


ΓòÉΓòÉΓòÉ 9.5. TicArea.Cfg ΓòÉΓòÉΓòÉ


; typical areas:
; AREA1 is "uplink to downlinks"
; AREA2 is "uplink to downlinks" and passthru
; AREA3 is "downlinks to uplink"
; AREA4 is bidirectional

FileArea AREA1 d:\file\area1 O I2:332/1 504.1 .2 1:2/3
FileArea AREA2 d:\file\area2 O -0 I2:332/1 504.1 .2 1:2/3
FileArea AREA3 d:\file\area3 I O2:5/1 3/1 332/504.2 .3
FileArea AREA4 d:\file\area4 * 2:5/1 3/1 332/504.2 .3

; some special areas with overrides

FileArea AREA5 d:\file\area5 O #2:332/500 I2:332/596 C555
FileArea AREA6 d:\file\area6 O S2:332/504.1 10:10/0 *100/1


ΓòÉΓòÉΓòÉ 9.6. Sample help file ΓòÉΓòÉΓòÉ


Command examples:

%Help       : For Help
%Query      : For a list of linked and available areas
%List       : Same as Query
%Linked     : For a list of linked areas
%Unlinked   : For a list of unlinked areas

=====================================================================

1* -1-COMM

Adds all areas whose tag begins with '1', deletes area '1-COMM'.

=====================================================================

+2*
-2-WINDOW
1-COMM

Adds all areas whose tag begins with '2', deletes area '2-WINDOW',
adds area '1-COMM'

=====================================================================

"Special" areas:

NODEDIFF - FidoNet nodelist (diff)
NODELIST - Region 33 (ZIPped)
ISNPTLST - Italian pointlist (from ISNMAIN)
NET-LIST - Non FidoNet nodelist (diff)

=====================================================================


ΓòÉΓòÉΓòÉ 9.7. Compress Definition ΓòÉΓòÉΓòÉ


;               Example Compress.Cfg definition file
;
; If you are already using a Compress.Cfg file with other programs,
; you do not need this one.
; Just make sure you use the correct switches to avoid case mismatch
; with case sensitive archivers, as ZIP/UNZIP.


Archiver ARC
     Extension     ARC
     Ident         0,1a
OS2  Add           arc aw5 %a %f
DOS  Add           pkpak -oct a %a %f
OS2  Extract       arc ew %a %f
DOS  Extract       pkunpak /r %a %f
OS2  View          arc vw %a
DOS  View          pkpak v %a
End Archiver


DOS Archiver PAK
DOS     Extension       PAK
DOS     Ident           -2,fe
DOS     Add             pak a %a %f
DOS     Extract         pak e /wn %a %f
DOS     View            pak v %a
DOS End Archiver


Archiver ZIP
     Extension     ZIP
     Ident         0,504b0304
OS2  Add           zip -jk %a %f        ; store in uppercase
DOS  Add           pkzip -a %a %f
OS2  Extract       unzip -qqnjC %a %f   ; case insensitive extract
DOS  Extract       pkunzip -n %a %f
OS2  View          unzip -v %a
DOS  View          pkzip -v %a
End Archiver


Archiver LH
     Extension     LZH
     Ident         2,2d6c68                        ; "-lh"
OS2  Add           lh a %a %f
DOS  Add           lha a /m %a %f
OS2  Extract       lh x %a %f /o
DOS  Extract       lha e /m %a %f
OS2  View          lh l %a /v /o
DOS  View          lha l %a
End Archiver


Archiver ARJ
     Extension     ARJ
     Ident         0,60ea
DOS  Add           arj a -e+ %a %f
OS2  Extract       unarj e %a %f
DOS  Extract       arj e -n %a %f
OS2  View          unarj l %a
DOS  View          arj l %a
End Archiver


Archiver RAR
     Extension     RAR
     Ident         0,526172211a0700
     Add           rar a -ep %a %f
     Extract       rar e -o- %a %f
     View          rar v -y %a
End Archiver